Dear Florian and others,

we have developed open-open source chromatography system control, acquisition and processing system many years ago

https://sourceforge.net/projects/chromulan/

but there are some users still. You can see references form research publications for example

https://scholar.google.com/scholar?q=%22CHROMuLAN%22

The project has been started by prof Jindrich and funded by PiKRON company when we have delivered instrument development and licenses to other/production company. But program is used by many to evaluate data even from other instruments setups. The design has been done initially in some ancient Delphi version and then in Delphi 6 which is used for production build/seldom maintenance till now. The users are mostly Windows oriented but I prefer and use GNU/Linux from middle nighties and have it as main/only desktop/development system for years.

I look on free-pascal progress from time to time,
I have even tested some old TurboVision project
on it decade(s) ago etc. And I gradually update CHROMuLAN in some spare time in a year and it runs with Lazarus including instruments control on GNU/Linux x86
32 and 64-bits already. I have tested even Raspberry Pi build and 64-bit Windows etc. and external projects state and my changes slowly converge to state that one day FPC build can reach quality to offer it to our users as standard.

But my main daily focus is motion-control, CAN communication, FPGA and SoC peripherals for Linux, RTEMS, NuttX as well as teaching of computer architectures teaching at Czech Technical University and even abroad.

We have been donated by two Milk-V Pioneer 64-core, RISC-V boxes by RISC-V international based on our
other activities

https://www.crowdsupply.com/milk-v/milk-v-pioneer/

and because they came at the same day as I have helped to prof. Jindrich with revival of HPLC instruments from our design at their university, I have come to wicked idea to test CHROMuLAN on that box.

The build of our communication driver (uLAN) run
smoothly on that box and device connected on the
first go. I have tested building of our Qt based
RISC-V simulator (QtRvSim) as the next step.
Again smooth.

So I have looked for RISC-V native compiler
binary and I have stubled over

http://fedora.riscv.rocks/koji/buildinfo?buildID=86978

But that is probably some old experiment form 2019 and cannot be used to build actual mainline.

I have had to go home after more alternative
unsuccessful attempts so I have setup RISC-V 64-bit Debian unstable chroot with qemu-static, bootstrapped FPC from mainline on x86 Debian, build FPC cross
for RISC-V by it and then build riscv64 to riscv64 compiler binary. That build has been partial
but allowed to combine that binary with cross
build units at the end .

I have continued with attempts to boostrap FPC
with that compiler in RISC-V chroot. It has more
problems, I have even tried something similar
with FPC-3.2.4 branch - that failed completely
on unrecognized riscv64-linux target and attempt
t regenerate makefiles did not succeed either.
So I have returned to the FPC mainline. The main
problems has been in ./fpmake for packages and utils.

With use of qemu-static strace feature and even
debugging stub and gdb-multiarch I have identified two strange problems when boostraping native
on RISC-V (patch/hack to move forward attached)

1) TProcess call to GetCompilerInfo in fpmkunit.pp failed with bad address. Same problem has been in ExecuteFPC. When I have explicitly reprocessed list of environment defines, it solved the problem. It looks like nill or unassigned state is not propagated correctly into TProcess.SysExecute and execve fails with errno = 14 EFAULT (bad address)

2) another problem is that attempt to write to standard output in fpmkunit.pp results in exception because descriptor or StdOut setup seems to be closed/invalid.

Boostraps and cross compiler build from same sources have no problems on x86. So may it be that could
help somebody more knowable to identify actual problem source on native RISC-V build.

The full Lazarus build fails on

9009) Assembling formeditingintf
units/riscv64-linux/nogui/formeditingintf.s: Assembler messages: units/riscv64-linux/nogui/formeditingintf.s:3366: Error: illegal operands `lui ireg32,1' units/riscv64-linux/nogui/formeditingintf.s:3367: Error: illegal operands `addiw ireg32,ireg32,-1736' units/riscv64-linux/nogui/formeditingintf.s:3368: Error: illegal operands `add ireg33,x5,ireg32' units/riscv64-linux/nogui/formeditingintf.s:3369: Error: illegal operands `ld x5,0(ireg33)' units/riscv64-linux/nogui/formeditingintf.s:3453: Error: illegal operands `lui ireg32,1' units/riscv64-linux/nogui/formeditingintf.s:3454: Error: illegal operands `addiw ireg32,ireg32,-1736' units/riscv64-linux/nogui/formeditingintf.s:3455: Error: illegal operands `add ireg33,x5,ireg32' units/riscv64-linux/nogui/formeditingintf.s:3456: Error: illegal operands `ld x5,0(ireg33)' units/riscv64-linux/nogui/formeditingintf.s:3540: Error: illegal operands `lui ireg32,1' units/riscv64-linux/nogui/formeditingintf.s:3541: Error: illegal operands `addiw ireg32,ireg32,-1736' units/riscv64-linux/nogui/formeditingintf.s:3542: Error: illegal operands `add ireg33,x5,ireg32' units/riscv64-linux/nogui/formeditingintf.s:3543: Error: illegal operands `ld x5,0(ireg33)' units/riscv64-linux/nogui/formeditingintf.s:3557: Error: illegal operands `lui ireg32,1' units/riscv64-linux/nogui/formeditingintf.s:3558: Error: illegal operands `addiw ireg32,ireg32,-1432' units/riscv64-linux/nogui/formeditingintf.s:3559: Error: illegal operands `add ireg33,x5,ireg32' units/riscv64-linux/nogui/formeditingintf.s:3560: Error: illegal operands `ld x5,0(ireg33)' /home/pi/repo/fpc/lazarus-git/components/ideintf/formeditingintf.pas(847) Error: (9007) Error while assembling exitcode 1 /home/pi/repo/fpc/lazarus-git/components/ideintf/formeditingintf.pas(847) Fatal: (10026) There were 2 errors compiling module, stopping Fatal: (1018) Compilation aborted

but lcl and other components can be build and when CHROMuLAN is build from commandline it seems to run and process data well when run under RISC-V qemu-static.

I plan to do testing on real RISC-V system next week or after I return from vacations.

Generally I congratulate to enormous amount of work done and ability to support new targets as well as keep support for old ones.

If you have interrest, I can try some other build, experiments and benchmarks when I have Milk-V boxes setup and stable running.

Best wishes,

Pavel

Hello all,

Pavel Pisa wrote

we have developed open-open source chromatography system control, acquisition and processing system many years ago https://sourceforge.net/projects/chromulan/

I have reproduced the full rebuild of free-pascal, Lazarus LCL and CHROMuLAN directly on Milk-V Pioneer box.

The picture demonstrating the CHROMuLAN processing data and running data acquisition from USB connected device is attached to my Mastodon post

https://social.kernel.org/notice/AkjYvergU6jrFAYJ9M

The problem with keeping virtual registers instead of mapping to RV64 hardware ones in full Lazarus make bigide build seems to be exactly reproducible on real hardware same as in user space QEMU RISC-V Debian in chroot install.

Assembling formeditingintf

...

I am on vacations next week (orienteering camp and do not plan take some kind of Internet connection).

This project is more of the curiosity for now but running the system on VisionFive 2 same as on Raspberry Pi could be alternative to replace Windows systems for some user in longer future. Processing power demand of CHROMuLAN is a niche.

I would be happy to continue to test our application with Lazarus, and test even FPC ecosystem on RISC-V and other hardware from time to time. Say, if you have some idea which kind of testing can help the FPC project. I can help with registers mapping problem as well if you specify which way to call, debug or modify FPC to get more information.

Best wishes and thanks for many years of your work,

Pavel

It smells like a bug in thlcgriscv.g_intf_wrapper