Recent

Author Topic: Lazarus for RISC OS  (Read 34552 times)

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #45 on: July 24, 2023, 04:47:16 pm »
Quote
If it ain't pretty close to Unix, don't bother.

Not so sure. I know both linux and riscos , and the linux rtl helps my thinking.

Quote
If you are really at home in your OS, going your own way is probably better.

Yes. That is the goal.

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

Haha ,, yes as a user I prefer windows over unix ( but macOS  is ok). However I know close to none of the windows internals. I have hacked a bit WindowsCE drivers , but I assume that is a bit different to the desktop.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12028
  • FPC developer.
Re: Lazarus for RISC OS
« Reply #46 on: July 24, 2023, 05:23:03 pm »
Quote
If it ain't pretty close to Unix, don't bother.

Not so sure. I know both linux and riscos , and the linux rtl helps my thinking.

Quote
If you are really at home in your OS, going your own way is probably better.

Yes. That is the goal.

It is not 100% either-or, you can get your feet wet with Linux, specially the syscall only part of the RTL and then replace it more and more with your own.

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

Haha ,, yes as a user I prefer windows over unix ( but macOS  is ok). However I know close to none of the windows internals. I have hacked a bit WindowsCE drivers , but I assume that is a bit different to the desktop.

I program Windows mostly as ordinary user. But I do use some vendor APIs for low level (network filter driver) hardware access. But the maintenance for the platform over time is just so much less.

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #47 on: July 24, 2023, 09:51:26 pm »
Small question.. I can't get arguments working.

I do this:

Fetches arguments from riscos ,, gives me a buffer with words containing null terminated strings
I save that to operatingsystem_parameter_argv . So I think this is the same thing as when in linux arguments is on stack.
I have tested to print it from start file and everything seems in order.

But! What does fpc do with that? I have tried to trace it to system.pp , but I don't think that any of the parameter procedures are entered.

I don't have envp ,,  (  made a empty buffer for it ) but I am skipping fpgetenv .. it gives me trouble. Might be that envp is nil and that exit() doesnt work.

IN the screenshot you can see my printout ( without spaces). up to "hellopas" is exename in full path .. paths looks quite different from other os's.


I tried with hardcoded filename.. The next thing that happens is STAT call for some directories unix directories / /usr/X11R6 /FPCDIR/ /path/to/cross and what not.
Interesting!
« Last Edit: July 25, 2023, 01:55:57 am by micken »

TRon

  • Hero Member
  • *****
  • Posts: 3930
Re: Lazarus for RISC OS
« Reply #48 on: July 25, 2023, 04:41:47 am »
But! What does fpc do with that? I have tried to trace it to system.pp , but I don't think that any of the parameter procedures are entered.
inside rtl/linux/system.pas is a line that reads {$I sysunixh.inc} which includes the contents of that include file in(side) the system unit.
 
The include file itself can be found as /rtl/unix/sysunixh.inc

In there is located following code:
Code: Pascal  [Select][+][-]
  1. {$if not defined(solaris) and not defined(darwin) and not defined(aix)}
  2. {$ifdef FPC_HAS_INDIRECT_ENTRY_INFORMATION}
  3. var argc:longint;
  4.     argv:PPAnsiChar;
  5.     envp:PPAnsiChar;
  6. {$else FPC_HAS_INDIRECT_ENTRY_INFORMATION}
  7. var argc:longint;external name 'operatingsystem_parameter_argc';
  8.     argv:PPAnsiChar;external name 'operatingsystem_parameter_argv';
  9.     envp:PPAnsiChar;external name 'operatingsystem_parameter_envp';
  10. {$endif FPC_HAS_INDIRECT_ENTRY_INFORMATION}
  11. {$endif}
  12.  

Which tells that the external symbol operatingsystem_parameter_argc is used as storage location for the variable argc, the external symbol operatingsystem_parameter_argv is used as storage location for the variable argv, and the external symbol operatingsystem_parameter_envp is used as storage location for the variable envp.

These variables are documented as argv, argc and envp and can be used anywhere by anyone, including the end user in (pascal) code.

The first sign of usage is inside unit system in function ParamStr (argv) and function ParamCount (argc). Since you shared to not have envp, I do not mention it. Keep it nil should do the trick.

That means that you won't see immediate/direct usage of the symbols operatingsystem_parameter_xxx (as for the most time it is (indirectly) accessed (it does get directly accessed a few times in the startup code inside unit system.pas).

regards,
I do not have to remember anything anymore thanks to total-recall.

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #49 on: July 25, 2023, 01:00:20 pm »
Quote
The first sign of usage is inside unit system in function ParamStr (argv) and function ParamCount (argc). Since you shared to not have envp, I do not mention it. Keep it nil should do the trick.

I can print argv and argc. BUT argv[0] is exe but argv[1] isn't source file only first character.

So something is wrong in my start file.. back to asm. :-)

Solved!


Unfortunately it doesn't help , command line no source.

I don't get this. The arguments is finalized in compiler/options. It depends on a cmd variable passed to compiler. That cmd is void.
« Last Edit: July 25, 2023, 03:24:07 pm by micken »

StefanRISCOS

  • New Member
  • *
  • Posts: 29
Re: Lazarus for RISC OS
« Reply #50 on: July 25, 2023, 03:30:00 pm »
@Micken
Slighty other topic:
Might the problems with RPCemu come from that is is ARMv6 and not ARMv7 compliant?
That is why also !Iris doesn't work on RPCemu.
Unlikely that the FP compiler tries to access Floiting Point instructions and crashed there....

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #51 on: July 25, 2023, 03:49:01 pm »
@Micken
Slighty other topic:
Might the problems with RPCemu come from that is is ARMv6 and not ARMv7 compliant?
That is why also !Iris doesn't work on RPCemu.
Unlikely that the FP compiler tries to access Floiting Point instructions and crashed there....

Dunno. My compiler seems to work better on new cpu compared to emulated StrongARM. It probably also helps to have gigabytes of ram.

I don't have a way to transfer the program to laptop now.. so stuck with emulator until next week. So it is possible that arguments are some kind of CPU related problem.
« Last Edit: July 25, 2023, 04:31:15 pm by micken »

StefanRISCOS

  • New Member
  • *
  • Posts: 29
Re: Lazarus for RISC OS
« Reply #52 on: July 25, 2023, 07:41:53 pm »
What about FTP? I can give you access .

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #53 on: July 25, 2023, 08:03:04 pm »
What about FTP? I can give you access .
No networking.

TRon

  • Hero Member
  • *****
  • Posts: 3930
Re: Lazarus for RISC OS
« Reply #54 on: July 26, 2023, 06:00:51 am »
Might the problems with RPCemu come from that is is ARMv6 and not ARMv7 compliant?
...
Unlikely that the FP compiler tries to access Floiting Point instructions and crashed there....
arm instruction sets supported by free pascal: https://wiki.freepascal.org/ARM_compiler_options#Instruction_sets
arm floating point options: https://wiki.freepascal.org/ARM_compiler_options#Floating_point_support
I do not have to remember anything anymore thanks to total-recall.

TRon

  • Hero Member
  • *****
  • Posts: 3930
Re: Lazarus for RISC OS
« Reply #55 on: July 26, 2023, 06:13:08 am »
Unfortunately it doesn't help , command line no source.

I don't get this. The arguments is finalized in compiler/options. It depends on a cmd variable passed to compiler. That cmd is void.
I have absolutely no idea where you are stuck (too little information).

If you are at the point where the compiler processes the command-line options (in which case you are already pretty far) then the code that you are currently trying to fix can be located (almost) anywhere in the source-tree (as at that point the system is already initialized and make use of Pascal functions like ParamCount and ParamStr.

Do note that when I said you can leave envp nil that this does mean that whenever the compiler tries to locate an environment variable that you need to compensate for that. As you are now seem to enter the domain of the compiler attempting to locate all kinds of stuff on the host that it needs in order to setup things properly.
« Last Edit: July 26, 2023, 06:43:10 am by TRon »
I do not have to remember anything anymore thanks to total-recall.

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #56 on: July 26, 2023, 09:42:35 am »

I have absolutely no idea where you are stuck (too little information).

If you are at the point where the compiler processes the command-line options (in which case you are already pretty far) then the code that you are currently trying to fix can be located (almost) anywhere in the source-tree (as at that point the system is already initialized and make use of Pascal functions like ParamCount and ParamStr.

Do note that when I said you can leave envp nil that this does mean that whenever the compiler tries to locate an environment variable that you need to compensate for that. As you are now seem to enter the domain of the compiler attempting to locate all kinds of stuff on the host that it needs in order to setup things properly.

It might be the emulator. But dunno really. Thanks for your reply. I will continue looking, but not doing much changes before I can test on real hardware.

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #57 on: July 26, 2023, 11:10:24 am »
mmap and munmap for extend and shrink memory regions is *very* problematic and needs some very clever hack.
The unixlib solves it with dynamic areas, and that can work. The problem is that it very quickly fills up the allowed
number of areas. Amiga have the Pooled functions. There is nothing like that in riscos. When thinking of it I feel
very much to give up. I guess that fpc needs the memory in a continues area. Right?

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12028
  • FPC developer.
Re: Lazarus for RISC OS
« Reply #58 on: July 26, 2023, 11:19:40 am »
mmap and munmap for extend and shrink memory regions is *very* problematic and needs some very clever hack.
The unixlib solves it with dynamic areas, and that can work. The problem is that it very quickly fills up the allowed
number of areas. Amiga have the Pooled functions. There is nothing like that in riscos. When thinking of it I feel
very much to give up. I guess that fpc needs the memory in a continues area. Right?

The Unix port, yes, since the original call was SBRK that essentially resized the data segment.  (mmap was a later generalization).

FPC in general however just requires you to implement a record with a number of procedure variables (search for tmemorymanager), however you see fit. E.g. windows in the end calls heapalloc https://learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapalloc

The Cmem just calls C heap functions

micken

  • Jr. Member
  • **
  • Posts: 82
Re: Lazarus for RISC OS
« Reply #59 on: July 26, 2023, 11:33:17 am »

The Unix port, yes, since the original call was SBRK that essentially resized the data segment.  (mmap was a later generalization).

FPC in general however just requires you to implement a record with a number of procedure variables (search for tmemorymanager), however you see fit. E.g. windows in the end calls heapalloc https://learn.microsoft.com/en-us/windows/win32/api/heapapi/nf-heapapi-heapalloc

The Cmem just calls C heap functions

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)?
« Last Edit: July 26, 2023, 11:39:54 am by micken »

 

TinyPortal © 2005-2018