FYI success build/run on Starfive Visionfive 2 SBC

[omac777]

I installed qt and necessary developer stuff on the VF2:

sudo apt-get install git htop curl libdrm-dev build-essential gdb gdb-source libboost-all-dev qmake qttools5-dev

Fetched the code, converted the .pro file to a Makefile then built the FpCodeNavigator binary

cd ~
git clone https://github.com/rochus-keller/FreePascal.git
cd FreePascal/
qmake CodeNavigator.pro 
make

From the following archived page I retrieved a useful piece of pascal example code and ran your fpCodeNavigator against it. https://web.archive.org/web/20181116101101/http://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply.html

cd ~
wget https://web.archive.org/web/20181116101101/http://www.musikwissenschaft.uni-mainz.de/~ag/tply/tply41a.zip
unzip tply41a.zip
cd tply41a/
~/FreePascal/FpCodeNavigator .

VOILA. It works on the VF2. NOTE: This doesn't install because fpc-compiler package isn't built yet for riscv VF2.

sudo apt-get install lazarus fpc fpc-source

[rochus-keller]

Thanks for the info; great to hear that it works. Looks like a nice SBC.

[omac777]

Unfortunately I have not had success to cross-compile FreePascal to riscv64 debian/riscv64 fedora. I wish there were packages easily available for debian/fedora, but there aren't.

Perhaps you code navigator could help to generate/transpile the free pascal compiler itself to C/C++ have a chance to build on riscv64 that way? Are all your parser analysis efforts in the hopes to do something like this?

Would it be less effort to take the syntax trees and instrument/add riscv64 support directly within the original pascal code itself? With all the AI coding support out there, is it possible to ask it to perform such a task?

[omac777]

I'm experiencing a lot of pain with the VF2 SBC since I can't do regular apt-get upgrade on the board. It's frozen in time on a snapshot at present from the manufacture starfive. Other developers have made attempts to make upgrades possible, but there is breakage and results in not being able to boot the board and reflashing a manufacture image to an sdcard/nvme; I've done that more than a handful of times and it's not something I enjoy doing. I think the ARM tv boxes, non-pi ARM SBC's and the newer RISCV64 SBC's all have these painpoints. I'm just a user and would prefer not to experience this pain, but I'm certain there are others who feel the same way about this. Why isn't ARM/RISCV hardware built with the same TLC as the x86_64 ecosystem? I don't know but I lack the patience/time/energy to endure this pain. It shouldn't be like this. It should be designed from the get-go to support the usual upgrade cycling for packages and kernels.

I'm under the impression tools like yours could alleviate this pain somehow if they were extended to provide some kind of capability to help port programming languages to other hardware targets. With all the AI that's out now, maybe this is possible?

[rochus-keller]

help to generate/transpile the free pascal compiler itself to C/C++ .. Are all your parser analysis efforts in the hopes to do something like this?

There was an intention to check whether I could re-use the FP compiler backend (not the whole compiler) for other languages (such as my Oberon+). The FP parser/navigator looked affordable since I already had a Lisa Pascal parser/navigator. But the FP language turned out to be an unspecified mess. But since I had already invested quite some time, I was ambitious to make the parser at least compatible with the the FP compiler source code, which succeeded to some extent.

The syntax is interpreted correctly and also cross-referencing works reasonably, but I am (probably) still far away from a complete mapping of the full semantics. Since the task is primarily based on trial and error, an effort prediction is difficult. But the compiler is heavily dependent on the RTL, whose huge source code is in turn incompatible with my parser at the moment. Again, an effort estimate is difficult.

Re-using the backend by transpiling the code to C++ is one of the options. But after studying the compiler source code with my navigator for a long time now, I doubt that this project could be done in a reasonable time. The whole thing looks more like a life's work. See also my notes in the readme.

Would it be less effort to take the syntax trees and instrument/add riscv64 support directly within the original pascal code itself?

Which means that you would use my FP parser and add a backend which directly generates machine code, i.e. no transpiler. This would then be a kind of full-blown alternative FP compiler, which means you would have to also add full FP language support and full semantic checking and error reporting. As a backend re-use of an existing infrastructure like LLVM would make sense. This would certainly easy cross-platform compilation, but since FP has deep low-level features by the end of the day you would still have to invest a lot of effort for every architecture and OS combination, as they do today for Clang. From my point of view this is even more effort than a life's work and can only be accomplished by sufficiently staffed teams with industry backing. Personally I would be not interested in such a project because my interest is not the FP language.

[rochus-keller]

Why isn't ARM/RISCV hardware built with the same TLC as the x86_64 ecosystem?

ARM is very well supported; it's best to use a board where there is Linux main line support; usually it takes some time until the main line keeps up; until then you have to depend on manufacturer custom Linux forks, if there is any at all. Concerning RISC V I'm still skeptical what use case it actually tries to improve and whether it will reach relevant industry acceptance at all. If it's just for hobby projects you're much better off with a Raspi board; even the Pico MCU is excellently documented and supported.