Lazarus for RISC OS

[marcov]

Reading Cmem gives me hope , looks like it uses malloc etc. That is perfectly doable without hacks.
I will do a pascal procedure to call swi's and probably a table with names / numbers. Where is a good place to make this global (in target)?

Have a look at the record definition at the top of inc/heap.inc    Those sysos* functions are what you need to provide (though in some cases you can provide NIL or a dummy function if you don't want to (yet)). These are the functions you have to implement (look at cmem for hints at the implementation)

Put these in sysheap.inc or under ifdef in unix/sysheap.inc if you still include the unix dir.

[micken]

Have a look at the record definition at the top of inc/heap.inc    Those sysos* functions are what you need to provide (though in some cases you can provide NIL or a dummy function if you don't want to (yet)). These are the functions you have to implement (look at cmem for hints at the implementation)

Put these in sysheap.inc or under ifdef in unix/sysheap.inc if you still include the unix dir.

I see. How much is unix port dependent on mmap? In my first tries I simply did new allocs and free's instead of mmap,munmap. It seemed to work for alloc (can be wrong here) , but with munmap it failed miserably.
I guess the address it gets are relative and not  the  initial address, right?

OK. Changed in unix/sysheap.. I am printing addresses and it free's addresses not alloced. But two differences in the output from fpc.. it complains about "disk full" and doesn't print error about the command line. the disk full message is before it enters Compile.

I have tried to track down DiskFree but as far as I can see it doesn't use that. But ,, I feel that my printouts is a bit hit and mis.

[StefanRISCOS]

@marcov
Is it right that there is no real overview document what parts of FPC or the Lazarurs IDE that show what parts / includes do what?

[marcov]

@marcov
Is it right that there is no real overview document what parts of FPC or the Lazarurs IDE that show what parts / includes do what?

Not really.  Keep in mind however that this is done by modifying the Unix RTL, while RISCOS isn't, so that complicates the matter.

[micken]

What might cause the disk full message? It prints that if hardcoding parameter in compiler/options and now also without that.
One guess is a failed "write", but very unlikely. I am tracing "open" and the only file that is opened is the error message file.
I added debug to write and can confirm that that guess is wrong.

When thinking .. probably alloc related since only change.

I do like this:
It relies on that r0 is the first argument and return value

Function Fprommap(len:size_t):pointer; [public, alias : 'ROFPC_SYSC_MMAP'];
begin
asm
  mov r3,r0
  mov r0,#6
  swi #0x1e
  mov r0,r2
end;
end;

[marcov]

What might cause the disk full message? It prints that if hardcoding parameter in compiler/options and now also without that.

There is a routine that translates *nix ERRNO values to FPC (Turbo Pascal) RTL errors. This probably causes this. See sysos.inc Errno2Inoutres (which calls posixtorunerror in that same file)

Does RiscOS have something like strace/ktrace/truss ? Such a syscall monitor can be useful in detecting which call gives an (unexpected?) error result.

[micken]

There is a routine that translates *nix ERRNO values to FPC (Turbo Pascal) RTL errors. This probably causes this. See sysos.inc Errno2Inoutres (which calls posixtorunerror in that same file)

Does RiscOS have something like strace/ktrace/truss ? Such a syscall monitor can be useful in detecting which call gives an (unexpected?) error result.

No. no such thing that I know about. Anyway back to "no source in cmd line",, Memory allocation works,, but not all are freed. I expect that it crash silently.

[micken]

Status:

I am moving out the swi dispatchers from the syscall.inc , with good results. Close but no cigar.

I still get no source on cmd line. That is in options.pas where it fails. argv is working.. I can print the source file from where in options it should find it. It doesn't find it.
If I hardcode the filename in options I get "can''t open myfile".. It doesn't try to open it.

I get the feeling that I lacks some glue between rtl and upper level compiler. Any ideas?

[TRon]

I get the feeling that I lacks some glue between rtl and upper level compiler. Any ideas?

Not really atm. If you are already that far then the origin must stem from one of the generic RTL functions (directly or indirectly) or from one of the units that the compiler includes (directly).

Did you already had a look at f.e. cfileutl.pas ? That implements some of the basic file i/o functionality for the compiler (cache).

[micken]

Not really atm. If you are already that far then the origin must stem from one of the generic RTL functions (directly or indirectly) or from one of the units that the compiler includes (directly).

Did you already had a look at f.e. cfileutl.pas ? That implements some of the basic file i/o functionality for the compiler (cache).

In options.pas there is a call to objpas.paramstr. Is that a thing that is supposed to be loaded externally? If I change it to system.paramstr I get a consistent behavior.
It finds the source in cmd line and gives error message ( can't open ). The open routine is never called.

I wonder about units.. Is they supposed to live on filesystem or can they be compiled in (prefered) ?

This is interesting:

strace fpc hello.pas 2>&1 |grep pas
execve("/usr/bin/fpc", ["fpc", "hello.pas"], 0x7ffd7dd96428 /* 23 vars */) = 0
Compiling hello.pas

On pc. It doesn't call open() on the sourcefile. How come? It opens itself (the exe).. for some reason.. then it does fork() right before it compiles.
fork() is not trivial to implement.

[TRon]

In options.pas there is a call to objpas.paramstr. Is that a thing that is supposed to be loaded externally? If I change it to system.paramstr I get a consistent behavior.

objpas.paramstr calls system.paramstr to retrieve the 0th parameter (name of executable).

It finds the source in cmd line and gives error message ( can't open ). The open routine is never called.

Do you already have all the file related RTL functions 'working' for riscos ?

That is one of the reasons I mentioned cfileutl.pas as it makes use of other (in RTL available such as system and sysutils) file related functions.

Perhaps I'm not understanding something but I noticed that riscos uses quite another file notation that I've never seen before (and as such would be a shitload of work to make them compatible for/with Free Pascal. The Amiga platform had the same problem but at least there the modifications where minimal, see also function Unix2AmigaPath)

I wonder about units.. Is they supposed to live on filesystem or can they be compiled in (prefered) ?

They live on the filesystem. Originally as .pas or .pp sourcecode-files which are compiled by the compiler into units (.ppu files) and object (.o files). By default they are located in the units/<platform> (e.g. arm-linux) directory (on a normal FPC installation).

If you compile your (own) source-code, the compiler will 'include' all the units/object files (hence all the caching for several directories), create an object for your code and feed all that to the linker which then creates an executable.

Not sure what exactly you meant with "compiled in" but in the end it is one single executable unless you are creating (system) libraries. The process is exactly the same as that of other compilers such as (gc)c except that units/ppu files are precompiled.

[micken]

OK.

I need to find a way to have a directory for units. Although the pc/linux fpc doesn't open anything.. or maybe the fork does.

About paths , yes they are *very* different. I will do something for converting .. possibly port a c program to pascal. But for units I think I just will rely on creating a dir called (insert of the default paths heer) , so /ppc something. The compiler will look for the path and riscos will find the directory, relative to working directory.
About fork .. I tried with strace -f now , and indeed it looks for units and opens my source file.
 

[TRon]

I need to find a way to have a directory for units. Although the pc/linux fpc doesn't open anything.. or maybe the fork does.

You can create an archive (make (cross)zipinstall) when you create a (cross-)compiler for arm that includes all units/files required for an installation. Since I'm not sure what you are actually using (in your debug sessions) you could also download a linux-arm tarball from sourceforge.

I have attached a tree structure of my (now obsolete, therefore almost clean) 2.6.4 installation of Free Pascal. Do note that it is a custom install, the directory structure is not corresponding to your typical windows/linux/macos installation of Free Pascal. Besides that, (cross)binutils are required as well.

Not sure what is your normal/daily poison and if you are able to extract tgz files.

[micken]

You can create an archive (make (cross)zipinstall) when you create a (cross-)compiler for arm that includes all units/files required for an installation. Since I'm not sure what you are actually using (in your debug sessions) you could also download a linux-arm tarball from sourceforge.

I have attached a tree structure of my (now obsolete, therefore almost clean) 2.6.4 installation of Free Pascal. Do note that it is a custom install, the directory structure is not corresponding to your typical windows/linux/macos installation of Free Pascal. Besides that, (cross)binutils are required as well.

Not sure what is your normal/daily poison and if you are able to extract tgz files.

Thanks for your file , will have a look!

I am building on Linux/pc. My debug session is in riscos. I am currently tracing the directories it calls stat on. The initial directory in riscos will not look like anything else.
RISCOS uses '.' as separator. It can have directories starting with '/'. So my compiler looks for "/something" and I have a directory named "/something".

I don't think I have use for the linux-arm version. I can see the units compiled in my source tree.
The crosscompiler (fpc) that produces my compiler binary does not use my start file if building a random pascal file. But right now it doesn't matter.

[TRon]

@micken
If your FreePascal compiler is able to create executables that you (after patching) can run (up to a point) on riscos then imho an easier approach is to start a new program and implement the file functions (or any other function/object/class that gives you issues) one by one, matching the Fee Pascal RTL functions. That should be much easier to debug/patch and you can directly see/note where things go wrong. At least that is how I would most probably approach it. If the compiler complains about a missing unit then you can create it and place it next to your example program.