Lazarus for RISC OS

[StefanRISCOS]

@TRon
RISC OS programs don't need any setup code when starting a program as they just claim the core for themselves until the program decides to allow other apps do some processing (that it is why it is called "Co-operative" multitasking.
For the start you don't need to care about it at all. The compiler just will run until it has done its compiling task and then hand over control to the next program (the OS).

Later can insert some WIMP_poll calls in the loop for the compiling to give to other apps also some CPU time which creates the impression of multitasking.
From the Book "https://www.brucesmith.info/raspberry-pi-risc-os-system-programming-revealed.html:
"Co-operative multitasking means that, once a program is running, it has full use of the CPU. With the exception of interrupts and other background operations, once your program is running all other programs are paused. This isn't very helpful if we want to run more than one program at once, so it's up to each program to yield the CPU on a regular basis so that other programs can run. Programs do this by calling SWI Wimp Poll. Control will only return from Wimp Poll to your program if there's some action to be handled (like a mouse button clicked on one of the programs windows). Alternatively you can elect for your program to receive null polls, which means the OS will return control to your program once all the other programs are done handling their own Wimp Poll events.

Wimp programs are therefore event-driven, something happens, a message is Issued through Wimp Poll and the event must handled, the event type being signified by a reason code. Once done, Wimp Poll again and wait until the next event happens. If you're program is trying to do some work (like copying some files or converting an image) it has to be split into small pieces that can happen between calls to Wimp Poll. Take too long and the desktop starts slowing down because other programs don't have enough CPU time to get their own work done. The important point here is that you have to write your code so that it remembers what you were last doing before the CPU is whisked away by Wimp Poll so that it can jump straight back at the point where it left off"

WIMP Poll                          https://www.riscosopen.org/wiki/documentation/show/Wimp_Poll
WIMP poll Idle                    https://www.riscosopen.org/wiki/documentation/show/Wimp_PollIdle
WIMP poll reason codes     https://www.riscosopen.org/wiki/documentation/show/Reason%20Codes

[StefanRISCOS]

There is also an ELFLoader
https://www.riscos.info/index.php/ELFLoader

[micken]

There is also an ELFLoader
https://www.riscos.info/index.php/ELFLoader

This is outdated and should not be used.

[TRon]

@TRon
RISC OS programs don't need any setup code ...

Thank you for that informative post Stephan. It does help for future development as each implementation has its own quirks . I am well aware how (cooperative) multitasking works in general but also in specific for example for the Amiga platform.

Alas for my current issues it is of no importance. A OS really expects you to respect some things with regards to CPU register initialization/usage etc. That is why ABI's and API's were invented.

This is outdated and should not be used.

That much I understood. The documentation is clear on that, even the wiki page itself. Though having said that I now have another keyword to search/grep for so thank you for mentioning to you both.

[micken]

Interesting .. I am home today and tried fpc on my riscos laptop (pinebook pro). I have only tried it with rpcemu (RiscPC emulator) before.
It behaves very different. Among others , BX LR works ( not surprised). But more surprised is that I don' get aborts. Only exceptions from fpc.
I think I will bring the laptop with me when going back from home tomorrow.

I need to define a riscos os target in order to move on now.. If I change linux rtl I can't build it since it affects host compiler.

You can see the attached screenshot. The first run it complains that it cannot find message file. I binary patched away that and that gave me the next report
I wonder when I will see a copyright etc. Maybe that is a part of message file.

[micken]

Some more progress:

I have implemented open and read calls. It opens the error msg file and reads it. I can print it. However it doesn't seem to use it??
It reads 8192 bytes. The msg file is 282kbytes.

I wonder which startup file that gets into a executable made by the arm compiler. If I build hello world with the cross compiler it builds for linux and not with the startup code that is used for the native compiler. There is not much work before I can try to compile something with the native compiler,

In screenshot:
First run is with printing from read. Second is without. I can see the copyright string in the file. but dunno how it is supposed to work,

[TRon]

I need to define a riscos os target in order to move on now.. If I change linux rtl I can't build it since it affects host compiler.

That is exactly what I'm doing (well, have to be a bit more careful there: trying) 

I wonder which startup file that gets into a executable made by the arm compiler.

Linux arm directory as in my previous explanations.

If I build hello world with the cross compiler it builds for linux and not with the startup code that is used for the native compiler.

I do hope so. But just to make sure what is the architecture of your host OS ? and what options do you use for cross-compiling ?

There is not much work before I can try to compile something with the native compiler,

Depending on what (cross) target you've chosen (linux, embedded or not, subarch type, etc) you might find that using linux as a base causes some issues because as you said riscos is not posix compliant (while the linux rtl does depend on posix functionality, again based on your chosen target). That is why I started adding riscos based on the AROS target (which might turn out to be the wrong choice in the end, dunno atm). It is up to/for you riscos people to decide if you wish to depend on posix functionality using (external) dependencies or implement a posix compatible layer (the latter very much not advisable but mention it just in case it floats your boat). Otherwise you can stick with using riscos available functionality (just as the aros target does) in which case the rtl needs to be implemented using that functionality.

[micken]

Replying on a bus now


I see my quick and dirty port as a experiment and for learning fpc internals.
The only posix like stuff I skipped is timezone detection. I need to sort arguments
properly. But after that I will see if the compiler works and what file it produces.
Up to now I have added syscall detection to the Linux syscall.inc and implemented
riscos swis. Seems to work just fine.


But you might be right that aros is a better base. I will follow the Linux path
up to something that works.

[TRon]

I see my quick and dirty port as a experiment and for learning fpc internals.

Aah, ok. Thank you for mentioning that. No problem and appreciated.

Note that Free Pascal uses/chooses/selects other startup code depending on circumstances (compiler options and what not *) but also note that usually when (cross)compiling also some 'native' stuff can get linked in your binary by the binutils that are used. The gcc (cross) compiler for riscos will most probably do that as well (crtbegin crtend etc). Free Pascal does that as well when configured as such and in case the target expects it (though fpc itself can get by without it, in which case it /might/ cause linker issues in the end).

(*) Would love to explain it better but then we get into nitty gritty details of the compiler targets, and their implementation (which is mostly undocumented/uncharted territory).

[micken]

Gcc is not involved for creating the native compiler and from what I can see also not for executables created by crosscompiler.

In the linux rtl for arm there is several *crt*. the prt one is used in the native arm compiler. I guess crosscompiler uses another
file. I have checked the binaries created , and they match the linux crt from rtl/linux/arm.

As for posix.. most stuff is self hosted and the communication with kernel is done with syscalls. The reason for why my compiler looks for FPC_ERROR_FILE
is that I skip location detection.

If using aros/arm as base I suggest doing pascal wrappers for riscos swis. The only way is to have asm code that do the actual swi calls.
When using "C" there are libraries for that, but I think that leaving gcc out is a good thing.

[marcov]

Gcc is not involved for creating the native compiler and from what I can see also not for executables created by crosscompiler.

In the linux rtl for arm there is several *crt*. the prt one is used in the native arm compiler.

FPC *nix uses prt* as startup for binaries that don't use libc, and cprt* for ones that do use libc (e.g. when -dFPC_USE_LIBC is defined, or cmem is imported, e.g. due to profiling)

Note that nowadays most mainline Linux targets use pascal startup instead of the old assembler ones.

If using aros/arm as base I suggest doing pascal wrappers for riscos swis. The only way is to have asm code that do the actual swi calls.
When using "C" there are libraries for that, but I think that leaving gcc out is a good thing.

have a look at e.g. rtl/linux/arm/*syscall*.inc

[micken]

have a look at e.g.

( was What do you look at)
OK ,, I didn't see the rest of that sentens. :-)
If you read my rants here I have modified rtl/linux/arm/syscall.inc to call riscos swi and that seems to work without issues.

I know perfectly well how to do swi calls and I also know the riscos kernel works.
One library is OSLib which gives you C functions for swis, but it doesn't give much advantage in the fpc context.

Not trying impress , but I have done 4 bringups of riscos to new arm targets. That means that I talk arm assembly pretty fluently.

[TRon]

Gcc is not involved for creating the native compiler and from what I can see also not for executables created by crosscompiler.

No, but Free Pascal has the opportunity to 'interact' with c libraries (dynamically/statically loaded/linked) in which case c conventions need to be followed. If that is something that the riscos target does not wish to support then that is up to you (riscos users/devs).

have a look at e.g.

( was What do you look at)
OK ,, I didn't see the rest of that sentens. :-)
If you read my rants here I have modified rtl/linux/arm/syscall.inc to call riscos swi and that seems to work without issues.

I know perfectly well how to do swi calls and I also know the riscos kernel works.

I believe marcov meant that you can have a look at where it si located and how fpc implements it. It basically/usually means copy-paste with some minor adjustments.

One library is OSLib which gives you C functions for swis, but it doesn't give much advantage in the fpc context.

That depends. see my previous remark but also note that things become a lot easier wrt porting when the RTL is able to rely on something more 'generic'. Most if not all OS are written predominantly using c.

Not trying impress , but I have done 4 bringups of riscos to new arm targets. That means that I talk arm assembly pretty fluently.

No one is questioning your capabilities. My background originates from 65xx and 68k asm but that isn't particularly helpful in trying to bring up a compiler such as fpc either (yes it is good to understand the generated asm code so that you can figure out why/where things go wrong but usually that is caused by something buried in the compiler and being able to figure out where exactly is usually more productive but requires knowledge on the (undocumented) internals of the compiler).

I do not know if I told in public or to stefan personally but because things are undocumented I am trying to write things down so that the situation can be improved (the documentation that does exist is pretty much outdated). It is pretty easy to figure out what files need to be touched by looking at the commit history of a (previous) bring-up but that doesn't really explain the why and nitty gritty details. What does become clear when you see such commit history is how for instance things influences others in the compiler, which startup-code is used and how to instruct the assembler/linker for a specific target. That is besides adding the RTL for the target and some other internal details of what a target supports (or not).

We are fortunate that the cpu is (already) supported by Free Pascal (otherwise that would have to done as well) and that FPC is already able to target (more or less) generic
operating systems for that CPU. That mans that we can have a look at what is already done and copy-paste whatever is required/supported (plus/minus some adjustments).

[micken]

Sigh! I have my riscos laptop now, but forgot to bring something that I can use to transfer files to it
No riscos emulator emulating RiscPC is capable to run my code,, I target armv7.

Most if not all OS are written predominantly using c.

riscos is 90% asm

I am tinkering with porting because of fun.. I can definitely live without fpc on riscos. But pascal was my second language after basic, so got a lot of memories from it. I think that compilers and kernels are interesting to work on.. . I enjoy reading disassembled binaries, patching without source code and so on. Live patching has helped a lot in this little adventure combined with objdump output.

[marcov]

I believe marcov meant that you can have a look at where it si located and how fpc implements it. It basically/usually means copy-paste with some minor adjustments.

Following the prototype and conventions (error handling) would make recycling the *nix/p*six rtl easier. That is not mandatory, you can implement the RTL OS dependent interface anyway you see fit, but there are some things to consider

One library is OSLib which gives you C functions for swis, but it doesn't give much advantage in the fpc context.

Right. If you regularly need to interface C libs that link to C runtimes, it can be useful to choose the *nix RTL.    Code reuse is also a bit higher with *nix interfaces, but deciphering the headers usually more complicated and the interaction between existing generic *nix code and target specific code is finicky.

I don't know what is wise in this case, but usually the closer an OS is to being a "true" *nix the better it is to use the *nix RTL, and vice versa. If it ain't pretty close to Unix, don't bother.

The *nix RTL promises some codereuse, but also has many pitfalls. If you are really at home in your OS, going your own way is probably better.

... one of the authors of the FPC *nix RTL who now is a happy Windows user