Lazarus for RISC OS lazarus / 23-Operating Systems ---------------------------------------------------------------------- StefanRISCOS · 2023-06-06 14:02 Hello I want to revive a topic about implementing Lazarus for RISC OS from Gerald Holdsworth: Are there any programmers in this community that would like to join in a project to release Lazarus for the ARM based OS : RISC OS? RISC OS was the first OS implemented on the now famous ARM processors. RISC OS is open source now. GCC 10.4 is available on RISC OS. It runs on any Raspberry Pi and it is also available as free emulator for Windows and Linux/MacOS (RPCemu). There is not really any program IDE available for RISC OS other than one for BBCBASIC (AppBASIC). So currently Lazarus would be for sure the most popular IDE on RISC OS. We made a poll about Lazarus and 74% of RISC OS users  who took part in the poll are interested in Lazarus. https://twitter.com/RISCOSproject/status/1662538079104532481 So we would mainly need som people who are familiar with the Lazarus code and implenting the Pascal compiler. We can find some people who will assist with the RISC OS part. For anyone interested in helping us I would offer our RISC OS Cloverleaf distro for free with a collection of most free applications available and also our modern filer "CLFiler". Please read the previously posted topic by Gerald in 2021: https://forum.lazarus.freepascal.org/index.php/topic,52467 regards Stefan ---------------------------------------------------------------------- PascalDragon · 2023-06-06 19:59 Quote from: StefanRISCOS on June 06, 2023, 04:02:17 pmHello I want to revive a topic about implementing Lazarus for RISC OS from Gerald Holdsworth: Are there any programmers in this community that would like to join in a project to release Lazarus for the ARM based OS : RISC OS? You first need to port FPC itself before you can even remotely think about porting Lazarus. For a slightly outdated example of porting FPC, please look here. Once you've ported FPC you then need to check whether you can use an existing widgetset like GTK or Qt or whether you need to implement a completely new widgetset for RISC OS. In the later case you might want to first start with a cross compiler as quite a lot of the widgetset needs to work correctly before the IDE will work. ---------------------------------------------------------------------- TRon · 2023-06-07 09:47 @StefanRISCOS: Just a note. When I treat myself as being totally oblivious to RiscOS, I surf over to https://www.riscosopen.org and start digging for the obvious when trying to port something. That usually entails finding a toolchain that I can use (usually for a existing c-compiler). Then I find out that RisOS itself is using it's own custom build utility (not familiar with it, no intention to either as it has no relevance for porting, let alone cross-compiling) that it uses a closed source c-compiler and that the source-code (I also assume headers) is not compatible with gnu-c. see also: https://www.riscosopen.org/wiki/documentation/show/Cross- building%20RISC%20OS Perhaps I am looking at the wrong locations but the things I was able to find isn't very encouraging, do you agree ? ---------------------------------------------------------------------- StefanRISCOS · 2023-06-07 15:30 @PascalDragon thanks for the link to the FPC porting. There are some ARM related ports already so we might not start at zero level there. system_arm_embedded system_arm_symbian But currently we cannot use aarch64 yet as RISC OS is still stuck to 32bit so aarch32. Parts of new RISC OS implementations has been adopted from Open BSD. I just found the reference of @Iproven about the Ultibo FPC for Raspberry https://ultibo.org/wiki/Building_for_Raspbian I think that might be the closest fit for an FPC on RISC OS. @TRon I think that the Lazarus UI looks quiet similar to RISC OS style. The only thing that is different that there is no top menu. There is a library called Toolbox that handels all window related stuff (gadgets?!) http://www.riscos.com/support/developers/toolbox/reseditor.html Is the Lazarus UI written based on Pascal or C? ---------------------------------------------------------------------- StefanRISCOS · 2023-06-07 18:17 @TRon There is also GCC 10.4 available. There is the Shared C library and the Toolbox library to access all windows elements. To edit window content there is a tool that is very much similar to Lazarus editor (when you scroll down the page you will see the screenshots). http://www.riscos.com/support/developers/toolbox/reseditor.html I think the RISC OS windows design is very much like Delphi style. More than MS Windows or MacOS. ---------------------------------------------------------------------- StefanRISCOS · 2023-06-08 09:12 @MarkMLl For unknow reason I cannot answer your private message. When I click on your Nickname it says: "You are not allowed to access this section". In the Message center there is no button to reply to your message also... So I answer you here: Yes Pascal for sure is not very popular anymore but the Lazarus IDE (Borland Delhpi IDE) is the easiest and fastest way to write powerfull office application. There is no AI features needed. When we have the Lazarus running on RISC OS it might be even possible to add C++ or Python as programming language in the far future. ---------------------------------------------------------------------- PascalDragon · 2023-06-08 10:26 Quote from: StefanRISCOS on June 07, 2023, 05:30:20 pm@PascalDragon thanks for the link to the FPC porting. There are some ARM related ports already so we might not start at zero level there. system_arm_embedded system_arm_symbian I never said that you'd start at zero. The link I gave you is for porting FPC for a new operating system under the assumption that the port for the processor is already available which is the case for RISC OS, because it's running on 32-bit ARM. What you need is cross binutils that support RISC OS as target, but run on a supported target (e.g. Linux, Windows, etc.), then you can setup a cross compilation toolchain and make sure that the RTL is running well enough that FPC itself can be compiled for RISC OS. Even more of the packages and such then need to be enabled for RISC OS so that you can then start having a dig at Lazarus. Quote from: StefanRISCOS on June 07, 2023, 05:30:20 pmI think that the Lazarus UI looks quiet similar to RISC OS style. The only thing that is different that there is no top menu. There is a library called Toolbox that handels all window related stuff (gadgets?!) http://www.riscos.com/support/developers/toolbox/reseditor.html Is the Lazarus UI written based on Pascal or C? It's name is LCL, not “Lazarus UI” and it's written in Pascal, which is why you need to have a fully working FPC first. And don't worry about GUI stuff before you don't have the compiler itself working. One step at a time or you'll simply overwhelm yourself. ---------------------------------------------------------------------- TRon · 2023-06-09 03:36 Quote from: StefanRISCOS on June 07, 2023, 05:30:20 pmIs the Lazarus UI written based on Pascal or C? The GUI of Lazarus itself is written in Pascal but it uses what we call a widgetset as a backend and depends on the platform/target. For instance there are widgetsets available for gtk, qt, windows, cocao etc. See also: https://wiki.lazarus.freepascal.org/Widgetset. Besides that there are custom drawn components that are (as the name implies) custom drawn components (think of a component as something that is able to represent a widget/gadgets). Quote from: StefanRISCOS on June 07, 2023, 08:17:46 pmThere is also GCC 10.4 available. There is the Shared C library and the Toolbox library to access all windows elements. Yeah but that is exactly the issue: all I was able to find (development wise) runs natively on RiscOS. Which is ofc. pretty neat (and in the end is what is best for RiscOS itself) but as PascalDragon wrote that is not how to port a compiler like Free Pascal. That always start by creating a cross-compiler and for that you need a (cross) toolchain. You talk about having a GCC compiler for (native) RiscOS. Does RiscOS host/store its own patches against the compiler or are they merged upstream in the (GCC) compiler itself ? ---------------------------------------------------------------------- StefanRISCOS · 2023-06-13 13:47 @TRon My programmer uses Linux with GCC SDK and  CLion as dev IDE to compile programs for RISC OS. BTW: Thanks all for the infos! ---------------------------------------------------------------------- TRon · 2023-06-14 05:12 Quote from: StefanRISCOS on June 13, 2023, 03:47:21 pmMy programmer uses Linux with GCC SDK and  CLion as dev IDE to compile programs for RISC OS. The website that host GCCSDK gives me a gateway timeout/ BAD gateway. And just now a "Sorry! This site is experiencing technical difficulties." The gists that I was able to find uses the same website for accessing the source-code. I am only a little versed with svn but it seems that the redirections to where the source-code is stored are not working for me. I retrieve svn errors like: - E020014: Can't find a temporary directory: Internal error - E170011: Repository moved temporarily to 'http://www.riscos.info/gccsdk/trunk/autobuilder. - E170011: Repository moved temporarily to 'http://www.riscos.info/gccsdk/trunk' - E175003: The server at 'https://www.riscos.info/gccsdk/trunk' does not support the HTTP/DAV protocol etc. ---------------------------------------------------------------------- StefanRISCOS · 2023-06-14 07:16 @TRon Ok I will have a look what is the problem with the site. ---------------------------------------------------------------------- StefanRISCOS · 2023-06-14 07:27 @TRon Are you using Linux or Windows? ---------------------------------------------------------------------- TRon · 2023-06-14 07:31 Quote from: StefanRISCOS on June 14, 2023, 09:27:20 amAre you using Linux or Windows? Linux, Debian Bookworm to be precise (x86_64). In case it matters: Firefox version 114.0.1 and svn version 1.14.2 (r1899510) ---------------------------------------------------------------------- StefanRISCOS · 2023-06-14 07:34 I just got word from one RISC OS programmer Micheal Grundlitz: I think FPC will compile pretty easy with gcc10 on gccsdk. Unixlib is almost a complete posix layer. So probably the Linux port could be used. ---------------------------------------------------------------------- TRon · 2023-06-14 07:48 @Stefan: The Free Pascal compiler is written in Pascal. The compiler startup- code does (is not suppose to) not rely on external libraries (except for libc). Before anything can be done there is need for a toolchain. Free Pascal relies on an (external) assembler and linker that are able to create 'correct' executables for the target. Hence I do not mind taking a small side-track with creating some examples with a c-compiler in order to see the toolchain in action (that way it is possible to investigate how the toolchain could be used with FPC: that is why I asked if the changes that your developers made to the gcc toolchain are hosted on your own website (usually in the form of patches) or if the changes are pushed upstream to the gnu directory so that GCC is able to target RiscOS out of the box) ---------------------------------------------------------------------- micken · 2023-07-21 21:26 Hello Ron! I understand that you have got lose ends from me over copy/paste The things I have done. Built fpc for arm linux with risc os binutils Hacked a lot in linux rtl. So it starts.. but doesn't get far. It would probably be easier to start with another rtl as base. AROS uses amiga shared libraries I guess. RISC OS uses fixed SWI calls for everything.. like SWI 0 , for putc SWI 2 for puts etc. I am not sure if I can dedicate time for bringing up fpc on risc os. But if you can help with a skeleton rtl , I could probably fill in the missing bits. RISC OS is not a posix system , even less than Amiga. So ... lots of troubles. Best regards, Michael ---------------------------------------------------------------------- TRon · 2023-07-21 23:32 Quote from: micken on July 21, 2023, 11:26:15 pmI understand that you have got lose ends from me over copy/paste I'm still in the process of evaluating. Usually I figure things out as I go along. RiscOS is fairly new to me. QuoteSo it starts.. but doesn't get far. It would probably be easier to start with another rtl as base. The platform needs to be added to the compiler internals to make things a bit more comfy, then some (elf) startup code is required (usually a copy of what c does but a bot more Pascalified for the compiler so anything related to register usage or used ABI is welcome). After that the first RTL bits can be added. Quote AROS uses amiga shared libraries I guess. Correct and for that it uses syscalls which is a concept only available for amiga like platforms (HASAMIGA) QuoteRISC OS uses fixed SWI calls for everything.. like SWI 0 , for putc SWI 2 for puts etc. I am not sure if I can dedicate time for bringing up fpc on risc os. But if you can help with a skeleton rtl , I could probably fill in the missing bits. RISC OS is not a posix system , even less than Amiga. So ... lots of troubles. The troubles are expected. Can I compare swi's with something like (back in the days of) ms-dos and interrupt calls ? Is there any documentation on how swi's are implemented, what their cpu register/stack usage is etc ? I already found some list of available swi's calls (additional links to documentation would be appreciated) but that does not explain how things are in registers ad how registers are stored on the stack. I am aware that the whole source-code for riscos is available but just like for you the repository of Free Pascal might perhaps look a bit overwhelming so does the riscos repository look for me atm  regards, ---------------------------------------------------------------------- micken · 2023-07-22 10:07 Startup code: RISC OS doesn't require much of startup code. I am used to assembly and the most simple app is almost empty. I will dissasemble such a app when home again ( having vacation now ). The call convention is strictly ARM standards, RISC OS is modeled after the ARM cpu since it is designed by the inventors of ARM. Current fpc status details: I have hacked in support for write and memory allocation. RISC OS doesn't have native support for mmap, but there are other ways to allocate memory. If I return -1 from the "mmap" call I get a nice error from fpc. I have noticed that fpc does call open and read and wonders what that expects. I am printing out the syscalls from the assembly routines. The problems that I am facing is bad pointers. It sooner or later fails with ldr str from memory. The fpgetenv fails in exit(). The PLD stuff doesn't work.. I Haven't found out where to config it to not using bx lr so I have binary patched that. I can follow the crashes and doing live patching. But ofc , it doesn't get very far. I can make it to read() call but after that I get get a abort on a address that isn't in ram. For getenv I just skipping it by " if defined(cpuarm)". SWIs You can find the docs here: https://www.riscosopen.org/wiki/documentation/show/HomePage SWI stands for Software interrupt Instruction  ( i think you know this ). RISC OS is a singletasking system with cooperative multasking window system bolted on top. The system is driven by SWI calls,, each application gives cpu time to the system by guess what , a SWI! If I do a tight loop in assembly , the system freezes. Running a cli app in a taskwindow ( terminal ) does simulate some more multitasking , since the taskwindow gives cpu time. But it still freezes on "B ." . I have a lot of projects going on, so not sure how much time I can spend with fpc. I hope that this message helped a bit , I have spent one day with this. :-) The picture shows the error if returning -1 :-) ---------------------------------------------------------------------- TRon · 2023-07-22 11:12 Thank you for your quick reply micken. QuoteI have hacked in support for write and memory allocation. RISC OS doesn't have native support for mmap, but there are other ways to allocate memory. Should be able to accommodate that as long as there is an alternative though in case wrong I would appreciate a heads up from one of the devs that know and happen to read this. QuoteI have noticed that fpc does call open and read and wonders what that expects. Depends, are you seeing those calls when using the linux or aros rtl as a base ? QuoteI am printing out the syscalls from the assembly routines. The problems that I am facing is bad pointers. It sooner or later fails with ldr str from memory. If the allocation fails to begin with then that would cause issues there. QuoteThe fpgetenv fails in exit(). Only works if/when riscos supports passing commandline arguments (argc, arv, argp) in a similar way as the rtl that is used for base (depending on the platform the registers/stack used to pass those values differ). QuoteThe PLD stuff doesn't work.. I Haven't found out where to config it to not using bx lr so I have binary patched that. Platform specifics need to be configured correctly inside the compiler defined settings. As said in my previous post, I am working on those bits but as I already/also expressed to Stefan I have never done a full port and since having worked on the AROS rtl a lot of things seem to have been changed internally for the compiler. Unfortunately there is no full documentation available on how to do a full port (I am trying to document the process as well). I start at the basics and work my way through as I go along. First goal would be for the compiler to be able to recognize the riscos target so that a cross- compiler can be build, initially using some fake startup-code and basic rtl. Right now I am adding things as needed and (re)building the compiler currently tells me I am (still) missing some things Just like you I have multiple projects going on and have reserved the summer break to (also) try and catch up with a few things with regards to this project. There is currently no real need for you to worry about things that could be done by someone else. Some assembly is probably required for the startup code, or at least to verify if the compiler creates it correctly and is usable by riscos (there I could use all the help I can get as my arm asm skills are next to none /and/ I am not familiar with riscos binaries). Thank you very much for the help so far. regards, edit: typo's ---------------------------------------------------------------------- StefanRISCOS · 2023-07-22 15:03 @Tron About ARM assembler in RISC OS: You can easily create ARM assembler programs inside the BBC BASIC: https://simplemachines.it/doc/www.heyrick.co.uk/assembler/basic.html http://www.riscos.com/support/developers/prm/asm.html I could sponsor you this book if you think it might be useful https://www.brucesmith.info/raspberry-pi-risc-os-beginners-assembly- language.html ---------------------------------------------------------------------- micken · 2023-07-22 16:27 @Ron Sorry for not quoting  .. better at email than forums I have sorted the stack and that gave me less errors. Is there a document covering the flow of compiler start? Right now I get: stat64,open,close and after that instruction fetch abort at a address not in ram. My guess is that it tries to check for a source file, but if open returns -1 it should just bail out , right? I also have the same for stat64 , returning negative. Instruction fetch abort is probably a branch with bx reg , where reg is corrupted. Haha found it. The big question is why! it branches to a fixed address?! Another interesting find , is that fpc thinks that file  is open , even when open returned negative. ---------------------------------------------------------------------- TRon · 2023-07-22 17:56 Quote from: micken on July 22, 2023, 06:27:27 pmSorry for not quoting  .. better at email than forums Don't worry. As long as it isn't a thread with over 5 individuals all shouting against each other at the same time then we'll be fine  QuoteIs there a document covering the flow of compiler start? No, not that I am aware of. But based on the AROS parts and Free Pascal in general I can take a stab sources reference:  https://gitlab.com/freepascal.org/fpc/source Please do not take offense if i insult your intelligence with some obvious remarks/statements (I have to assume that like me you know nothing about this stuff). The compiler executable (fpc) program file can be found at compiler/utils/fpc.pp The "main start" of that program can be found at the bottom "begin" "end." pair But, Pascal allows for units to be included in their "uses" section at the top. For fpc.pp file it explicitly includes unit Sysutils. Each included unit /could/ include initialization code (executed before the main program start) and finalization code (executed after main program start end) and ordered in uses order (for init, for fina the order is in reverse). Those initialization and finalization portions can explicitly be defined by using their respective keywords "initialization" and "finalization" that define a section that contains the code that is executed. If there isn't such a section explicitly defined but the unit does have a begin ... end. pair listed in its implementation section then that is equivalent to the initialization section. For details see https://www.freepascal.org/docs- html/current/ref/refse112.html What is not explicitly mentioned in the code is that every program that get compiled also (automatically) includes the so called system unit (part of the rtl). So, falling back to aros (as it is for me the simplest example) the system unit can be found at rtl/aros/system.pp If you take a closer look at that unit then there is a initialization section (not explicitly defined) that gets executed. That is basically the first code (for initializing the rtl) that is executed. If you take a closer look at the directory rtl/aros then you can also find some other files (which ones are present depend on the platform) and some directories that contain processor specific startup code. In our case the arm directory would be the most interesting. In there is a file named "prt.as" and is something that should look a bit more familiar to you (even though the code is specific to/for aros). You can find a similar structure for Linux in the directory rtl/linux/ though there you are able to find many more cpu directories and their content is also a bit more overwhelming (too much for me to explain) but do have a look at the files inside the arm directory again as some of it might look familiar for/to you. Going back to rtl/aros there you can also find a file named "si_prc.pp". I would advise to have a look there as that should look familiar to you (at least when running through a debugger that supports symbols and you have your Free Pascal code (fpc.pp for example) compiled with a (for your debugger) supported debug format. The rest is as we say history, as we now have enough information to grep around to locate all the used symbols and subroutines that are used by the system routine. The only part that makes things more complicated is that common parts for some of the code is stored in a generic include directory and can be overridden by a 'local' include file (it is not always obvious when/if that happens so can get become lost at times in trying to trace the program flow). Is that enough information to get you started with understanding things a bit better ? What might perhaps be helpful to know as well is that you can for example compile a simple helloworld program with the compiler and have free pascal output the asm output for you (fpc -al hello_world.pas) so that you can match that asm output with what you see in the debugger. The fpc produced asm code can fairly easy be traced back to its Pascal equivalent by grepping the Free Pascal source-tree for functions and symbols names. For more details on compiler switches see: https://www.freepascal.org/docs-html/user/userap1.html regards, ---------------------------------------------------------------------- micken · 2023-07-22 18:18 Thanks! Very welcome. There is no debugger for elf binaries in risc os. So the only way is to rely on faults addresses combined with objdump on compiler system and printouts. ---------------------------------------------------------------------- TRon · 2023-07-22 18:41 Quote from: micken on July 22, 2023, 08:18:26 pmThere is no debugger for elf binaries in risc os. So the only way is to rely on faults addresses combined with objdump on compiler system and printouts. Ah, that is unfortunate. In that case we would have to disassemble a c compiler generated example code and compare that against startup code generated by Free Pascal (a simple hello world example would suffice for such a task), that is unless the arm asm (c might perhaps suffice as well) startup code for riscos is listed/documented somewhere. Do you happen to know if that is the case or perhaps you know that code by heart ? PS: forgot to mention that fpc.pp is actually a frontend to the(actual) compiler which is named pp.pas. I also noticed the mention of swi's somewhere in the source-tree so that seem to be accounted for (needs verification) PPS: also note that you are going way to faaast for me  As soon as I can get the compiler to recognize/support the basics for the riscos target then I/we can start thinking of experimenting with some startup-code. ---------------------------------------------------------------------- micken · 2023-07-22 19:01 Quote from: TRon on July 22, 2023, 08:41:16 pmQuote from: micken on July 22, 2023, 08:18:26 pmThere is no debugger for elf binaries in risc os. So the only way is to rely on faults addresses combined with objdump on compiler system and printouts. Ah, that is unfortunate. In that case we would have to disassemble a c compiler generated example code and compare that against startup code generated by Free Pascal (a simple hello world example would suffice for such a task), that is unless the arm asm (c might perhaps suffice as well) startup code for riscos is listed/documented somewhere. Do you happen to know if that is the case or perhaps you know that code by heart ? PS: forgot to mention that fpc.pp is actually a frontend to the(actual) compiler which is named pp.pas. I also noticed the mention of swi's somewhere in the source-tree so that seem to be accounted for (needs verification) Here is a example of a riscos executable in AOF format ( not elf ). Not much going on. OS_GetEnv givs you the commandlne which in turn can be made a list with another swi. This is a assembly written app. If you mix in the clibrary it will be much more complex. But that isn't needed for fpc. 00008000 : E1A00000 : .. á : MOV     R0,R0 00008004 : E1A00000 : .. á : MOV     R0,R0 00008008 : E1A00000 : .. á : MOV     R0,R0 0000800C : EB00001B : ...ë : BL      &00008080 00008010 : EF000011 : ...ï : SWI     OS_Exit 00008014 : 00000090 : ... : MULEQ   R0,R0,R0           ; *** Rd=Rm or Rd=R15 00008018 : 00000000 : .... : ANDEQ   R0,R0,R0 0000801C : 00000000 : .... : ANDEQ   R0,R0,R0 00008020 : 00000000 : .... : ANDEQ   R0,R0,R0 00008024 : 00000000 : .... : ANDEQ   R0,R0,R0 00008028 : 00008000 : .€.. : ANDEQ   R8,R0,R0 0000802C : 00000000 : .... : ANDEQ   R0,R0,R0 00008030 : 00000020 :  ... : ANDEQ   R0,R0,R0,LSR #32 00008034 : 00000000 : .... : ANDEQ   R0,R0,R0 00008038 : 00000000 : .... : ANDEQ   R0,R0,R0 0000803C : 00000000 : .... : ANDEQ   R0,R0,R0 00008040 : E1A00000 : .. á : MOV     R0,R0 00008044 : E04EC00F : .ÀNà : SUB     R12,R14,PC 00008048 : E08FC00C : .Àà : ADD     R12,PC,R12 0000804C : E99C000F : ..œé : LDMIB   R12,{R0-R3} 00008050 : E24CC010 : .ÀLâ : SUB     R12,R12,#&10       ; =16 00008054 : E59C2030 : 0 œå : LDR     R2,[R12,#48] 00008058 : E3120C01 : ...ã : TST     R2,#&0100          ; =256 0000805C : 159CC034 : 4Àœ. : LDRNE   R12,[R12,#52] 00008060 : 008CC000 : .ÀŒ. : ADDEQ   R12,R12,R0 00008064 : E08CC001 : .ÀŒà : ADD     R12,R12,R1 00008068 : E3A00000 : .. ã : MOV     R0,#0 0000806C : E3530000 : ..Sã : CMP     R3,#0 00008070 : D1A0F00E : .ð Ñ : MOVLE   PC,R14 00008074 : E48C0004 : ..Œä : STR     R0,[R12],#4 00008078 : E2533004 : .0Sâ : SUBS    R3,R3,#4 0000807C : EAFFFFFB : ûÿÿê : B       &00008070 00008080 : EF000010 : ...ï : SWI     OS_GetEnv 00008084 : E1A0D001 : .Ð á : MOV     R13,R1 00008088 : EF000002 : ...ï : SWI     OS_Write0 0000808C : EF000011 : ...ï : SWI     OS_Exit ---------------------------------------------------------------------- TRon · 2023-07-22 19:06 Quote from: micken on July 22, 2023, 09:01:26 pmHere is a example of a riscos executable in AOF format ( not elf ). Not much going on. OS_GetEnv givs you the commandlne which in turn can be made a list with another swi. Oh, that is perfect to start with. The only thing that could make it better is some documentation on what is done for what reason (some used instructions are clear of what they do but not why as i am unfamiliar with the kernel/io of riscos). Perhaps I'm able to figure it out myself along the way. I take it there is no difference for riscos wrt startup code when a program is started either from a shell or the GUI (e.g. same register usage for both situation) ? the Amiga/Aros target differentiate between the two situations. ---------------------------------------------------------------------- micken · 2023-07-22 19:17 Quote from: TRon on July 22, 2023, 09:06:27 pmQuote from: micken on July 22, 2023, 09:01:26 pmHere is a example of a riscos executable in AOF format ( not elf ). Not much going on. OS_GetEnv givs you the commandlne which in turn can be made a list with another swi. Oh, that is perfect to start with. The only thing that could make it better is some documentation on what is done for what reason (some used instructions are clear of what they do but not why as i am unfamiliar with the kernel/io of riscos). Perhaps I'm able to figure it out myself along the way. I take it there is no difference for riscos wrt startup code when a program is started either from a shell or the GUI (e.g. same register usage for both situation) ? the Amiga/Aros target differentiate between the two situations. No difference .. apart from that a WiMP app is assumed to poll events .. if not system freeze. It also needs to be a new "task". A cli app can also be a WiMP task if needed. I can double click on my little executable and it starts in a window that you can't move .. and assuming you return somehow in your code .. you can press space in order to continue riscos. ---------------------------------------------------------------------- TRon · 2023-07-22 19:24 Thank you very much micken. Unfortunately I need to call it quits for today (duty calls). ---------------------------------------------------------------------- micken · 2023-07-22 19:50 Quote from: TRon on July 22, 2023, 09:24:12 pmThank you very much micken. Unfortunately I need to call it quits for today (duty calls). Thanks to you! A difference from a elf file is that the address info is correct.. ie starts at &8008. This means it can be *loaded and debugged with simple break commands. In theory it can be done with a elf file,, but it needs to be linked with a start address.. as it is normally everything is from 0x0. The start/load address is a part of the elf loader. ---------------------------------------------------------------------- micken · 2023-07-22 20:53 The elf file can (with a bit of change in header) be converted to acorn format with the tool elf2aif. The resulting binary can be used with debugger. Unfortunately it didn't work taht well with fpc.. dunno .. anyway screenshot attached ---------------------------------------------------------------------- StefanRISCOS · 2023-07-23 08:52 @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 · 2023-07-23 10:17 There is also an ELFLoader https://www.riscos.info/index.php/ELFLoader ---------------------------------------------------------------------- micken · 2023-07-23 10:56 Quote from: StefanRISCOS on July 23, 2023, 12:17:29 pmThere is also an ELFLoader https://www.riscos.info/index.php/ELFLoader This is outdated and should not be used. ---------------------------------------------------------------------- TRon · 2023-07-23 11:24 Quote from: StefanRISCOS on July 23, 2023, 10:52:51 am@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. Quote from: micken on July 23, 2023, 12:56:30 pmThis 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 · 2023-07-23 19:25 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 · 2023-07-23 23:58 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 · 2023-07-24 09:26 Quote from: micken on July 23, 2023, 09:25:37 pmI 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)  Quote from: micken on July 24, 2023, 01:58:46 amI wonder which startup file that gets into a executable made by the arm compiler. Linux arm directory as in my previous explanations. QuoteIf 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 ? QuoteThere 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 · 2023-07-24 10:05 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 · 2023-07-24 10:28 QuoteI 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 · 2023-07-24 11:40 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 · 2023-07-24 11:48 Quote from: micken on July 24, 2023, 01:40:41 pmGcc 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. QuoteIf 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 · 2023-07-24 12:03 Quote 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 · 2023-07-24 12:14 Quote from: micken on July 24, 2023, 01:40:41 pmGcc 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). Quote from: micken on July 24, 2023, 02:03:51 pmQuote 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. QuoteOne 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. QuoteNot 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 · 2023-07-24 14:11 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. Quote 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 · 2023-07-24 14:37 Quote from: TRon on July 24, 2023, 02:14:43 pm 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 QuoteOne 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 ---------------------------------------------------------------------- micken · 2023-07-24 14:47 QuoteIf 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 · 2023-07-24 15:23 Quote from: micken on July 24, 2023, 04:47:16 pmQuoteIf 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. QuoteQuote... 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 · 2023-07-24 19:51 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! ---------------------------------------------------------------------- TRon · 2023-07-25 02:41 Quote from: micken on July 24, 2023, 09:51:26 pmBut! 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][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i {$if not defined(solaris) and not defined(darwin) and not defined(aix)}{$ifdef FPC_HAS_INDIRECT_ENTRY_INFORMATION}var argc:longint;    argv:PPAnsiChar;    envp:PPAnsiChar;{$else FPC_HAS_INDIRECT_ENTRY_INFORMATION}var argc:longint;external name 'operatingsystem_parameter_argc';    argv:PPAnsiChar;external name 'operatingsystem_parameter_argv';    envp:PPAnsiChar;external name 'operatingsystem_parameter_envp';{$endif FPC_HAS_INDIRECT_ENTRY_INFORMATION}{$endif}  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, ---------------------------------------------------------------------- micken · 2023-07-25 11:00 QuoteThe 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. ---------------------------------------------------------------------- StefanRISCOS · 2023-07-25 13:30 @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 · 2023-07-25 13:49 Quote from: StefanRISCOS 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.... 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. ---------------------------------------------------------------------- StefanRISCOS · 2023-07-25 17:41 What about FTP? I can give you access . ---------------------------------------------------------------------- micken · 2023-07-25 18:03 Quote from: StefanRISCOS on July 25, 2023, 07:41:53 pmWhat about FTP? I can give you access . No networking. ---------------------------------------------------------------------- TRon · 2023-07-26 04:00 Quote from: StefanRISCOS on July 25, 2023, 03:30:00 pmMight 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_o ptions#Floating_point_support ---------------------------------------------------------------------- TRon · 2023-07-26 04:13 Quote from: micken on July 25, 2023, 01:00:20 pmUnfortunately 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. ---------------------------------------------------------------------- micken · 2023-07-26 07:42 Quote from: TRon on July 26, 2023, 06:13:08 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 · 2023-07-26 09:10 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 · 2023-07-26 09:19 Quote from: micken on July 26, 2023, 11:10:24 ammmap 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 · 2023-07-26 09:33 Quote from: marcov on July 26, 2023, 11:19:40 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)? ---------------------------------------------------------------------- marcov · 2023-07-26 09:47 Quote from: micken on July 26, 2023, 11:33:17 amReading 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 · 2023-07-26 10:16 QuoteHave 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 · 2023-07-26 12:15 @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 · 2023-07-26 12:32 Quote from: StefanRISCOS on July 26, 2023, 02:15:28 pm@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 · 2023-07-26 13:04 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 · 2023-07-26 14:39 Quote from: micken on July 26, 2023, 03:04:24 pmWhat 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 · 2023-07-26 14:44 Quote from: marcov on July 26, 2023, 04:39:38 pm 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 · 2023-07-26 21:39 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 · 2023-07-27 06:34 Quote from: micken on July 26, 2023, 11:39:17 pmI 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 · 2023-07-27 11:48 Quote from: TRon on July 27, 2023, 08:34:46 am 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 · 2023-07-27 12:09 Quote from: micken on July 27, 2023, 01:48:07 pmIn 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). QuoteIt 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) QuoteI 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/ (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 · 2023-07-27 12:32 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 · 2023-07-27 13:00 Quote from: micken on July 27, 2023, 02:32:22 pmI 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 · 2023-07-27 13:21 Quote from: TRon on July 27, 2023, 03:00:00 pm 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 · 2023-07-27 13:28 @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. ---------------------------------------------------------------------- StefanRISCOS · 2023-07-27 13:40 about file/folder syntax in RISC OS: Why not make a RISCOSify(path.filename) call for each file name that converts from UNIX to RISC OS style? ---------------------------------------------------------------------- TRon · 2023-07-27 13:59 Quote from: StefanRISCOS on July 27, 2023, 03:40:46 pmWhy not make a RISCOSify(path.filename) call for each file name that converts from UNIX to RISC OS style? Something like that, yes. But I'll have to see the bigger picture first before I know for sure that is (going to be) the right approach. There is also the matter of the other way around, and if it is at all possible, though I suspect it will as you also have a gcc compiler (and thus capable of using c file i/o functionality). I really need to have a closer look at those c-sources... ---------------------------------------------------------------------- micken · 2023-07-27 14:41 Quote from: TRon on July 27, 2023, 03:28:34 pm@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. Not sure if I understand. Do you mean a standalone program? In C? Pascal? I am implement syscalls as I go. It will work sooner or later. I guess we can do a libc enabled port.. would make life a lot easier. unixib which is the library it would use implements most if not all functionality of a posix system. I am going home tomorrow and will be able to run it on real hw,,, probably can be better results. I will also give you a tar-ball of my source tree. I have probably done a lot of mistakes because of not knowing the sources well enough. ---------------------------------------------------------------------- micken · 2023-07-27 22:12 I now face that fpc reads from stdin. I have implemented it using OS_ReadLIne32 (https://www.riscosopen.org/wiki/documentation/show/OS_ReadLine32 ) I attach a screenshot. Bah I missed a branch in the read swi dispatcher .. so perhaps it doesn't do stdin. Will see. Right.. no stdin I attach a screenshot .. it ends with a stat on hellopas.pp I don't actually do stat right now , only return 0x0. But for stat to work paths and sufixes needs to be sorted properly .. so that might be the logical next step. ---------------------------------------------------------------------- TRon · 2023-07-28 11:47 Quote from: micken on July 27, 2023, 04:41:38 pmNot sure if I understand. Do you mean a standalone program? In C? Pascal? Yeah, a standalone program written in pascal, f.e.: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i program hello;begin  writeln('hello world');end.  Which is ofc the exaggeration of minimalistic test/example-code. The startup-code for such a program is exactly the same as for the compiler (program startup, intialization by the system unit etc) though less dependent on other units (and their exposed/used functionality). The compiler is in that regards such a complex program and relies on much (other) functionality that such a simple example simply lacks. Additional functions to such minimalistic example can then be added (copy-paste from existing RTL (other platform that matches most) or implement a custom written version that works for riscos). That way you are able to test/verify specific functionality for debug purposes. It that regards it is the same process that I have to do: try to get the compiler to produce something that is able to run on riscos without errors using a minimalistic RTL implementations. That allows for writing/testing other (RTL) functionality inside such a simple example so that in case of errors (source)code can be tested and adjusted when necessary. QuoteI will also give you a tar-ball of my source tree. I have probably done a lot of mistakes because of not knowing the sources well enough. Your endeavors so far are a really good indication for me as well as I would run into the exact same issues that you currently run into (there might be a few less, there might be a few more) so it would very much be appreciated if (in the end or whenever is convenient) you are able to share what you've encountered so that It is possible to apply the proper fix (not that I mind replicating what you did but that would make it possible to add support for riscos a bit quicker). Do note that I am still not at a convenient point with my progress, as soon as I have something going that is helpful I'll share so that you can work with that). As I told stefan (not sure if it was public or not), Officially I haven't even really started. QuoteI guess we can do a libc enabled port.. would make life a lot easier. unixib which is the library it would use implements most if not all functionality of a posix system. That is something that I can't decide for you as the userbase is the one who has to work with the final product. If it was up to me personally then I would opt for the easiest/quickest road (but that might proof to be the wrong choice on the long run, I can't tell due to lack of experience with/on riscos). If the c compiler also relies on these libraries then it would imho be the better/quicker choice. Note that for example there is also a minimalistic implementation for someone that would like to address old(er) amigas that allows for you to just bang your way around the hardware, so something like that is a possibility for riscos as well (the negative side-effect is as for any asm developer that you must supply most (if not all) your own routines to be able to accomplish certain tasks). regards, ---------------------------------------------------------------------- StefanRISCOS · 2023-07-28 19:55 Here is some background on the path syntax in RISC OS: Comparison: Windows    C:\progs\test\unit1.pas Linux      /home/progs/test/unit1.pas RISC OS    SCSIFS:4.$.progs.!test.unit1 (filetype pas) In RISC OS the first part is the filesystm (eg. ADFS, IDEFS, SCSIFS, RAM, FAT32FS, CDFS, HOSTFS (RPCemu)) Second part is the drive number (0,1,2,3,4,5,6,7) Third part is the root sign "$" Following parts are the subfolder path. Last part is the actual filename. There is no extention in RISC OS for the file type. The file type is saved as part of the file info. Sadly it is not possible to have same names with different extentions (file types) as files are not accessed with the file type just by the name that doesn't include the file type. Also as standard in RISC OS there is no difference with upper or lower case names. This can be activated but it is not the standard setting. So for example for C the solution for this dilema is solved by subfolders that have the name "o","c"and "h". So in case Pascal needs also different file types with same file name same convention might be used: RISC OS    SCSIFS:4.$.progs.!test.pas.unit1 In RISC OS the (!) is used to represent a program folder that includes some set of files like: !Boot     (file type "Obey")   This file is run by the OS when the (!) folder is seen first time.                                This is used to setup paths for some files or sets file types. !Run      (file type "Obey")   This file is run when the user starts the app by a double click.                                Here normally the loading of modules is done or version numbers checked                                before the actual !Runimage is started. !Sprites  (file type "Sprite") In the image file the icon of the app is stored that is shown in the filer.                                There is normally two files !appname (68 x 68 pixels) and                                sm!appname (34 x 34 px) But the images can be bigger also like 140 x 68 px. Sprites   (file type "Sprite") Here all the icons are saved that are used in the window definitions. !Runimage (file type "Absolute")  This is the actual program code. !Help     (file type can be text, PDF or basically any file)   This file is started when use the menu entry                                "Help" in the filer of the selected file. It will start the program                                associated with the file type and load the file. Res       (file type "Resource")  In this file all windows, toolbars and menues are stored for the program.                                   It can be edited by !ResEdit. !ResEdit looks actually very similar like                                   the  window editor of Lazarus / Borland Delphi. But Lazurus is better                                            structured than !ResEdit.                                   With this Resource files also an internationalization can be achieved by                                   saving the files for different languages in a subfolder "resources". The neat thing about the (!) Pling folders is that they hide all files that are not usefull for the normal user. So if the program needs some data it will be stored in !app.data . ---------------------------------------------------------------------- micken · 2023-07-28 20:10 QuoteThe startup-code for such a program is exactly the same as for the compiler I need to look into this.. so far crosscompiler put wrong start code in the binary. when compiling test. Thanks for your long reply. I think I will follow the suggested route with a testprogram , just need to figure how to make that work. I have just started to add ppu's to my riscos compiler. I need to implement seek.. there is no such thing in riscos.. but I can do a dummy read from 0x0 and up to the desired offset. Then do the real read at the current file pointer. As for paths.. I do a directory , example "system" with a file "ppu" inside that makes riscos find system.ppu relativly to current dir. If a libc can handle all low level stuff then I think you should try building it with gcc/libc. If you look in gccsdk/autobuilder there is a port of newer gcc. In the latest one malloc/free is handled  pretty well compared to gcc4. ---------------------------------------------------------------------- TRon · 2023-07-29 08:06 Quote from: micken on July 28, 2023, 10:10:50 pmI need to look into this.. so far crosscompiler put wrong start code in the binary. when compiling test. You could try and replace the default used startup (compiled) object file with your own. In such a case you would have to recompile all units that rely on them though because FPC uses a checksum for ppu files (and refuses to continue when not recompiled). Quote I need to implement seek.. there is no such thing in riscos.. If I would have to take a stab at it (riscos internals noob) I would look at lseek implementation for the c compiler (https://www.gnu.org/software/libc/manual/html_node/File-Position- Primitive.html). It is possible to either use libc alternative and/or implement in (native) Pascal. In case the latter there is no law against peeking how it could be implemented. Most basic (RTL) functionality (between c and pascal) is pretty much similar (sometimes there are small diffs such as order of parameters or some limitation/extension that can usually be accounted for. At the least the naming differs (most of the time)). Quote but I can do a dummy read from 0x0 and up to the desired offset. Then do the  real read at the current file pointer. As for paths.. I do a directory , example "system" with a file "ppu" inside that makes riscos find system.ppu relativly to current dir. if I understood correctly the circumflex could be used for relative path schemes. What is unclear for me with what is mentioned in the user documentation is if that only applies to full path schemes, only applies to "current directory" (if there exist such a thing) and/or if it can be used multiple times in a pathname. The 255 character limit (as I understood there is might pose a problem but there are other platforms supported by FPC that have similar limitations (and work correctly). I have tried to locate the technical documentation for file (name) related handling but was unable to find it. QuoteIf a libc can handle all low level stuff then I think you should try building it with gcc/libc. If you look in gccsdk/autobuilder there is a port of newer gcc. In the latest one malloc/free is handled  pretty well compared to gcc4. See also my answer regarding c implementation. That is also one of the things I meant with "the bigger picture" (that I mentioned in one of my previous posts). If we can get a small workable RTL working using our own code then we can continue to work from there. The only thing I am not sure of if that is feasible (though to your expertise seems to indicate it might be possible to come up with a small/quick RTL implementation). It also depends a little on how quick you/we wish for things to happen. With regards to your "input" problem. How does your terminal/shell handle this situation ? I mean, a shell usually has some basic functionality with regards to files and piping to input/output handles. I have seen some shell functionality being mentioned in the online documentation (but I do not fully understand/grasp the implication wrt (other) os internals). ---------------------------------------------------------------------- TRon · 2023-07-29 08:13 Quote from: StefanRISCOS on July 28, 2023, 09:55:23 pmHere is some background on the path syntax in RISC OS: Thank you for that extensive description stefan, it is very much appreciated as it adds some things in addition to what the user manual wrote (at least it makes me understand things a lot better). So, am I correct to conclude that in that case it is not possible to have filenames with a dot in their name (as it is used for indicating a separation between directory/folder names) ? If that is the case, then I have to assume that whenever you would for example download a file with an extention that the (OS?) filing system automatically takes care of such encounters ? How does that work in practice ? Is that (officially) documented somewhere ? fwiw: I am familiar with filenames not indicating anything wrt file type. For example the Amiga uses file type descriptors based on internal byte-sequence recognition but it does allow for dots in their file/directory names. Often you can find there a filename such as mod.some_game_name.some_title.with.dots.some_author.with.dots but sometimes a user prefers to use  some_game_name.some_title.with.dots.some_author.with.dots.mod instead (some users are more familiar indicating some form of filetype with the last dot extention). Point being that the position of the dots themselves do not matter (but are allowed). ---------------------------------------------------------------------- micken · 2023-07-29 11:07 @TRon I found a seek replacement today, unfortunately the return value from my seek function gets corrupted , or I have some bug in my code. Both issues are possible.  I also found a better way to alloc memory, but haven't implemented yet. Is it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash, ---------------------------------------------------------------------- TRon · 2023-07-29 11:58 Quote from: micken on July 29, 2023, 01:07:02 pmIs it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash, Sorry, I lost you there mate (perhaps it is me having an off day). Which printouts and what do you mean with volatile in that context (and speaking of which, what exactly is the context) ---------------------------------------------------------------------- micken · 2023-07-29 12:36 Quote from: TRon on July 29, 2023, 01:58:53 pmQuote from: micken on July 29, 2023, 01:07:02 pmIs it possible to have printouts "volatile" , it seems like they are randomly not printed. Ofcource it can happen because of a crash, but I don't get why it happens before crash, Sorry, I lost you there mate (perhaps it is me having an off day). Which printouts and what do you mean with volatile in that context (and speaking of which, what exactly is the context) Sorry! I have sprinkled my code with Writeln. A lot f times the printouts doesn't happen. Is there a better way to print from compiler? ---------------------------------------------------------------------- StefanRISCOS · 2023-07-29 13:47 Quote from: TRon on July 29, 2023, 10:13:00 amQuote from: StefanRISCOS on July 28, 2023, 09:55:23 pmHere is some background on the path syntax in RISC OS: So, am I correct to conclude that in that case it is not possible to have filenames with a dot in their name (as it is used for indicating a separation between directory/folder names) ? If that is the case, then I have to assume that whenever you would for example download a file with an extention that the (OS?) filing system automatically takes care of such encounters ? How does that work in practice ? Is that (officially) documented somewhere ? On the normal RISC OS system files from other OS is correctly dispayed but with "/" instead of ".". The module that does it is MimeMap that can be found in !Boot.Resources.!Internet . But it is not implemented in RPCemu so there you must manually set the file type. We have implemented a function in !CLfiler that does it automatically SHIFT+S for all selected files. On RISC OS there is not to many programs that can process all filetypes that are available on Windows/Linux. So not for all extentions there exists file type definitions on RISC OS. FOr example JFIF and EXIF is set as JPEG. YOu can see that on the screenshot of !CLFiler. ---------------------------------------------------------------------- TRon · 2023-07-29 17:02 Quote from: micken on July 29, 2023, 02:36:19 pmI have sprinkled my code with Writeln. A lot f times the printouts doesn't happen. Is there a better way to print from compiler? No need to be sorry. Now, I get it  I don't know if your emulator and/or OS has some way to display (debug) output as that would be a better option then. For example the Amiga has some functionality in place for that and the FPC port also includes a sysdebugln function. It is basically a (pascal) subroutine that outputs text to an available output (device). So in case the OS/Emulator has provision for something like that then i would advise to use it. Now that i know i also understand your volatile remark a bit better: try to use shortstrings e.g. var s: shortstring or var s: string[10]. The first denotes a (oldstyle) pascal string that is able to store max 255 characters while the latter allocates 10 bytes for such a string. Note though that pascal strings (whether shortstring or ansistring) always store their length in their zero indexed byte. see also https://www.freepascal.org/docs-html/ref/refsu9.html and if in case you wish to know about all available string types, see https://wiki.freepascal.org/Character_and_string_types ---------------------------------------------------------------------- TRon · 2023-07-29 17:11 Quote from: StefanRISCOS on July 29, 2023, 03:47:33 pmOn the normal RISC OS system files from other OS is correctly dispayed but with "/" instead of ".". The module that does it is MimeMap that can be found in !Boot.Resources.!Internet . But it is not implemented in RPCemu so there you must manually set the file type. We have implemented a function in !CLfiler that does it automatically SHIFT+S for all selected files. On RISC OS there is not to many programs that can process all filetypes that are available on Windows/Linux. So not for all extentions there exists file type definitions on RISC OS. FOr example JFIF and EXIF is set as JPEG. YOu can see that on the screenshot of !CLFiler. The important part for me to know if it is at all possible to represent a dotted filename in riscos so that it can be accessed in a similar way as other platforms do. If that requires registering a filetype then so be it. There is simply need to be able to access files that have exactly the same filename but only differ in extention (that is something that can not be altered easily as all the file(name) related functionality depends on that behaviour). So for example, the source of a Pascal unit is named myunit.pas (or .pp), the compiled unit is named myunit.ppu and the assembled object file is named myunit.o. See for example https://wiki.freepascal.org/File_extensions which list some of the extentions  that are used by the pascal/lazarus infrastructure (and their filenameonly part can all be the same, residing in the same location/directory). ---------------------------------------------------------------------- StefanRISCOS · 2023-07-30 11:56 Quote from: TRon on July 29, 2023, 07:11:43 pm The important part for me to know if it is at all possible to represent a dotted filename in riscos so that it can be accessed in a similar way as other platforms do. If that requires registering a filetype then so be it. There is simply need to be able to access files that have exactly the same filename but only differ in extention (that is something that can not be altered easily as all the file(name) related functionality depends on that behaviour). No it is not possible. That is why I suggest to create a RISCOSifyPath(pathfilename) function to solve that problem. It will prevent typing errors when you try to adopt path/filenames manually which then will create bug that you have to search for for hours or days. The "." could be replaced by "_" or "-" or as C does in RISC OS use subfolders that are names as the used extention in other OS. .pas = folder pas .inc  = folder inc etc... So I would suggest that we have inside !FreePascal a folder "files" and then subfolders pas, inc, compiled etc. Other important RISC OS rules for folders: Config files and temporary files are located in the !Boot.Resources.AppName folder. Like this it is prevented to copy unnessary files or overwrite config files when upgrading or copying the application. So I guess the compiler files should be located in the temporary follders in !Boot. Attached as screenshot example how !FreePascal and !Lazarus folders could look like. I would prefer to call it FreePascal as FPC might not ring a bell with every computer user. This are only dummy files! (not that anyone thinks that the programs are finished already) ---------------------------------------------------------------------- micken · 2023-07-30 13:41 Regarding paths If I file comes from nfs/smb hello.pas became hello/pas and that is the way it should be., unixlib routines handles it that way ( from what I remember ) Status: I get error in rtl/inc/heap.inc There is an error before this as well. poc := poschunk(pointer(pmc) - (pmc^.size shr fixedoffsetshift));    32238:       e5970000        .word   0xe5970000     end; . I Memory allocation seems to work , so not sure what might cause this abort It is right after it asks for "system.pp" after doing some seek. system.pp is a source file .. why does it want that? ---------------------------------------------------------------------- StefanRISCOS · 2023-07-30 14:24 Quote from: micken on July 30, 2023, 03:41:31 pmRegarding paths If I file comes from nfs/smb hello.pas became hello/pas and that is the way it should be., unixlib routines handles it that way ( from what I remember ) Yes that way should be fine too. That the programmers should decide what is the easiest way. ---------------------------------------------------------------------- PascalDragon · 2023-07-31 19:32 Quote from: micken on July 28, 2023, 10:10:50 pmQuoteThe startup-code for such a program is exactly the same as for the compiler I need to look into this.. so far crosscompiler put wrong start code in the binary. when compiling test. Thanks for your long reply. I think I will follow the suggested route with a testprogram , just need to figure how to make that work. Just write a test program and compile that with your cross compiler. Using a test program to test specific functionality is much more useful than trying to immediately get the compiler running for a new platform, because as writting by others already the compiler is much more complex and needs many RTL functions. With a test program you can concentrate on specific functionality. ---------------------------------------------------------------------- micken · 2023-07-31 20:10 Quote from: PascalDragon on July 31, 2023, 09:32:52 pm[ Just write a test program and compile that with your cross compiler. Using a test program to test specific functionality is much more useful than trying to immediately get the compiler running for a new platform, because as writting by others already the compiler is much more complex and needs many RTL functions. With a test program you can concentrate on specific functionality. Right. Hello world worked directly! But! I don't see any traces of it loading anything ( units etc), and it print a few more printouts than I have. ReadLn  also works ,, and reading from files! Very happy .. I can see that my seek() routines works Code: [Select]program hello; begin         Writeln('Hello Begin');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello');         Writeln('Hello end'); end. ---------------------------------------------------------------------- TRon · 2023-08-01 05:32 Quote from: micken on July 31, 2023, 10:10:11 pmRight. Hello world worked directly! Fantastic ! Congratulations with that progress. QuoteBut! I don't see any traces of it loading anything ( units etc), That is/was the whole point  If you (cross)compile your example-code then you will not find any mention of loading units simply because they are compiled and  linked into the same executable. What might be noticeable however, is that in case there is initialization code inside a unit (that your example code uses), that this initialization code will be executed _before_  your main program start. To simplify: in your example code is a begin and an end. Any "pascal" code in a used unit that resides in the initialization section of that unit is executed before the begin of your example program and any "pascal" code in a used unit that resides in the finalization section of that unit is executed after the end of your example program. But because that is a bit of uncontrollable situation (just as is using a unit use all it's functionality and pray that it will not crash) you can add functionality to that example-code in order to test that (specific) functionality. For example, the system unit has the categorized functionalities as mentioned in https://www.freepascal.org/docs- html/rtl/system/index.html Whatever you deem the most important (for now) or most interesting is eligible for testing. Take for example the file functions You can write a small test program (examples but the source-tree also contains all kind of example code as well), (cross)compile that example and test if that works for riscos. In case you run into an issue and it is (as far as you know) not related to something that you've already implemented then it needs a closer look (else back to the drawing board ) . In such case you can copy the original code (Linux was your base, so look there first) of a specific function (say for example, you run code which crashes in the append function) and copy the implementation of the append function located in the Linux rtl to your example application which will then use that specific implementation of append (you have overridden the original append function). You can modify your append function, add/remove functionality, add debug, make it crash on purpose and what not. Since your debugging asm, some asm specific code that you can recognize (nop nop) might be helpful in such case. That way you should be able to figure out where and why something goes wrong and at the same time be able to try a fix. The only thing that can not be done in such a way are intrinsics as they are (more or less) part of the compiler itself. By doing so, step by step, you are able to (finally) end in a situation where it might be possible to attempt to (cross)compile the compiler for riscos (that is a long road) that is why the advise is given to start with cross-compiling. Quoteand it print a few more printouts than I have. Can you determine if it is Pascal or Riscos that is causing that ? At first glance it looks like a buffer not being flushed (in order). Quote ReadLn  also works ,, and reading from files! That is impressive. Are you able to use 'normal' (file)handles for that ? QuoteVery happy .. I can see that my seek() routines works Ok, my example mentioned the function append but could just as well have been mentioning the function seek. Admittingly, if Pascal is not really your virtue then you might find it all a bit too much. In that case you would have to wait a little (if you are looking at me in particular) or perhaps someone else is willing/able to help you with that right now (as said it is exactly the same thing I would have to do: compile a test program, see if it runs, if not figure out why, what and where, try to fix it and re-try. That is unless I am already sure why it fails and simply need to add the fix). ---------------------------------------------------------------------- TRon · 2023-08-01 05:59 Quote from: StefanRISCOS on July 30, 2023, 01:56:13 pmNo it is not possible. That is why I suggest to create a RISCOSifyPath(pathfilename) function to solve that problem. It will prevent typing errors when you try to adopt path/filenames manually which then will create bug that you have to search for for hours or days. ... Ok, noted. thank you very much for elaborating on that (it was not all clear from what I've read/understood) and the example (solution) that you provided. It is an interesting approach (even though micken mentioned another approach). QuoteThis are only dummy files! (not that anyone thinks that the programs are finished already) oh, I was already booking my ticket to a far away vacation ---------------------------------------------------------------------- StefanRISCOS · 2023-08-01 09:16 Quote from: TRon on August 01, 2023, 07:59:39 amNo it is not possible. That is why I suggest to create a RISCOSifyPath(pathfilename) function to solve that problem. It will prevent typing errors when you try to adopt path/filenames manually which then will create bug that you have to search for for hours or days. ... Ok, noted. thank you very much for elaborating on that (it was not all clear from what I've read/understood) and the example (solution) that you provided. It is an interesting approach (even though micken mentioned another approach). It is still usefull to use such a function RISCOSifyPath(pathfilename) with Micken's simple solution (unit1.pas -> unit1/pas) as it will be easy to adopt new folder structure as all that will be organised in that function. So no need to go back in all file declarations in all libraries. Just a one-stop change in the RISCOSifyPath(). ---------------------------------------------------------------------- micken · 2023-08-01 09:41 Quote Ok, my example mentioned the function append but could just as well have been mentioning the function seek. Admittingly, if Pascal is not really your virtue then you might find it all a bit too much. In that case you would have to wait a little (if you are looking at me in particular) or perhaps someone else is willing/able to help you with that right now (as said it is exactly the same thing I would have to do: compile a test program, see if it runs, if not figure out why, what and where, try to fix it and re-try. That is unless I am already sure why it fails and simply need to add the fix). It is the lower level function. I have followed this example: https://www.freepascal.org/docs-html/rtl/system/read.html And that file i/o causes calls seek for each step. Quote That is impressive. Are you able to use 'normal' (file)handles for thatNormal risc os handles. But they are also integers, so they can be used without much change. Quote Can you determine if it is Pascal or Riscos that is causing that ? At first glance it looks like a buffer not being flushed (in order). Probably riscos. But I don't know at this point , could be anything. I attach the output  of the file reading program. the lines of ############################ is after Read. As you can see, it does a extra read at the end, printing the last '.' twice. ---------------------------------------------------------------------- micken · 2023-08-01 12:36 BlockRead also works fine , en no extra at the end: I have not implemented file write , but it should be easy. A bit tired today , so not sure if I will do it right now. ---------------------------------------------------------------------- micken · 2023-08-01 20:06 I fixed "Write to file". The output from Writeln is a bit messy.. can be that I actually output characters from asm as debug.. I think it might confuse the "stream", but not sure. You can see in "pasout" that all text has been copied , included the first 'p' that is missing in the printout. ------------------------------ And possibly a bug. ---------------------------------------------------------------------- TRon · 2023-08-02 07:50 @micken Seems you are in your element there micken. Bravo ! @stefan Most definitely though for the initial bring-up for a cross-compiler it is not a priority. Being able to work with local files would be more helpful at first (would be tough enough to bend the existing implementation(s)) . ---------------------------------------------------------------------- micken · 2023-08-02 08:53 QuoteSeems you are in your element there micken. Bravo ! If the system unit is builtin I wonder why the compiler loads it from disk? It loads system.ppu and system.pp ( which is a sourcefile??) Perhaps crosscompiler does this as well. The real problem for the native compiler is the failure in heap management. Is there a requirement for a aligned address and in that case , is it 4k or something else? ---------------------------------------------------------------------- TRon · 2023-08-02 09:39 Quote from: micken on August 02, 2023, 10:53:30 amIf the system unit is builtin I wonder why the compiler loads it from disk? Because that is what a compiler does when it loads a source-code that needs to be compiled. The system unit is implicitly used/loaded for any source-code that it compiles. During the compilation process, the compiler tries to find the (pre)compiled (system) unit, loads the information (names of functions and their implementation etc)  and tries to compile the generated code, thereby turning it into objects that are linked together using the linker to finally turn it into a (single) executable. QuoteIt loads system.ppu and system.pp ( which is a sourcefile??) Yes, because if a unit's source-code was modified the compiler needs to recompile the unit into a ppu file. If you (cross)compile with >$ fpc -B -va helloworld.pas then the compiler will output (almost) everything it does during a compilation process. QuotePerhaps crosscompiler does this as well. Yes, see above mentioned command to see for yourself. QuoteThe real problem for the native compiler is the failure in heap management. Is there a requirement for a aligned address and in that case , is it 4k or something else? Yeah, usually dictated by the processor, see f.e. https://developer.arm.com/documentation/101754/0619/armlink- Reference/Scatter-loading-Features/The-scatter-loading- mechanism/Placing-the-stack-and-heap-with-a-scatter-file?lang=en Thus, how is riscos compiled (what processor, what options, what ABI etc) ? Perhaps the riscos c-compiler has some information listed as I was unable to obtain such information from the available riscos resources (unless diving into its source-code). ---------------------------------------------------------------------- micken · 2023-08-02 09:50 Quote Thus, how is riscos compiled (what processor, what options, what ABI etc) ? Perhaps the riscos c-compiler has some information listed as I was unable to obtain such information from the available riscos resources (unless diving into its source-code). It depends on target. Right now I am in emulator so StrongARM. The native pascal compiler is simply plain arm. I don't think it targets any fancy stuff, since it works in emulator. I notice that heap manager tries to align to 8-byte itself. I will play a bit more. riscos in itself follows the standards. Is it possible to print the addresses alloc returns? It is pointers and I don't know how to print the address. ---------------------------------------------------------------------- TRon · 2023-08-02 10:05 Quote from: micken on August 02, 2023, 11:50:31 amIs it possible to print the addresses alloc returns? It is pointers and I don't know how to print the address. Unit system has a function named hexstr. I was just wanting to ask if your allocmem implementation (swi call) takes alignment into account ---------------------------------------------------------------------- marcov · 2023-08-02 10:08 inttostr('$'+s); also works ---------------------------------------------------------------------- micken · 2023-08-02 10:54 Quote from: TRon on August 02, 2023, 12:05:42 pmQuote from: micken on August 02, 2023, 11:50:31 amIs it possible to print the addresses alloc returns? It is pointers and I don't know how to print the address. Unit system has a function named hexstr. I was just wanting to ask if your allocmem implementation (swi call) takes alignment into account  It is configurable. It is quite interesting. The critical part is in the mem lists themself. The same operation works a lot of times until it suddenly fails. https://github.com/fpc/FPCSource/blob/main/rtl/inc/heap.inc#L989 The destination is probably a bad pointer ,, but I have no clue why it suddenly is that. I have printed the destination address and what I assume is the derefed pointer. They all looks good. Unless.. The only thing I can think of is if  my alloc returns less than it is told. But I doubt it. ---------------------------------------------------------------------- StefanRISCOS · 2023-08-02 15:25 Quote from: micken on August 02, 2023, 12:54:26 pm The only thing I can think of is if  my alloc returns less than it is told. But I doubt it. Well to test that you could just add some bytes more and see if it works then... right? PS: I get already excited  to be able to program in Pascal soon :-P ---------------------------------------------------------------------- PascalDragon · 2023-08-02 20:23 Quote from: micken on August 02, 2023, 10:53:30 amQuoteSeems you are in your element there micken. Bravo ! If the system unit is builtin I wonder why the compiler loads it from disk? It loads system.ppu and system.pp ( which is a sourcefile??) The compiled System unit is statically linked into every FPC application (or at least those functions used are). Thus no loading occurs here. The compiler however loads the System unit from the file system, because it has no knowledge about the System unit in particular, it only expects to find certain symbols inside that unit when parsing it (or with the precompiled unit). The System unit linked into the compiler and the System unit that is linked into programs compiled by the compiler can be totally different (e.g. the compiler can be compiled by 3.2.2 thus being linked against the 3.2.2 System unit while at the same time compiling the System unit for 3.3.1). ---------------------------------------------------------------------- micken · 2023-08-02 21:03 Quick question about inline asm: I am trying to change the way I allocate ram. For that to work I need to have some global variables that is persistent. code Code: [Select]adr r8,dynname Point r8 to area name which is declared like this ( with a bunch of others): Code: [Select] var    dynno: Integer;    dynad: Integer;    dynsz: Integer;    dynname: String = 'fpc'; for storing stuff I do Code: [Select]adr r0,dynno mov r1,#1 str r1,[r0] Non of it works.. In the arm-linux syscal file ldr instruction is used with variable names.. but if I do that I get instant abort. Right now I get zillions of unnamed areas until system crash completely. rtl/linux/arm/syscall.inc uses ldr reg,argument. If i do that and try to access it , abort. If I do ldr reg,=variable I get (as expected) the contents of what ever address variable is in the binary. adr is for me the natural instruction, but no luck, In the asm help page I get a x86 example and that use data transfer from variable. Hrnf,, I can declare .byte and set my name.. hoping  that setting .word(s) would do the trick for the orthers .. But! They aren't zeroed. How can that be? Also in the global variable scenario it seems like setting the  integers to = 0 in the "var" section has no effect. ---------------------------------------------------------------------- micken · 2023-08-02 21:07 QuoteThe compiler however loads the System unit from the file system, because it has no knowledge about the System unit in particular, it only expects to find certain symbols inside that unit when parsing it (or with the precompiled unit). Thanks for the clarification (again ) ---------------------------------------------------------------------- TRon · 2023-08-03 09:31 Quote from: micken on August 02, 2023, 11:03:59 pmQuick question about inline asm: When you (cross)compile your code, add the option -al. That produces an assembler output (in a .s file next to your project) including the line numbers from the source. Check if the resulted assembler code make sense for you (it probably generated something you did not anticipated), if that still does not make things more clear then consider posting the output from the generated assembler file (if only a small test-project that resembles your issue). Quote from: micken on August 02, 2023, 11:03:59 pmIn the asm help page I get a x86 example and that use data transfer from variable. Unfortunately the use(age) of (inline) assembler is poorly documented and in case there is something it is (mostly) oriented at intel. In order to understand a little better I make small test programs, compile it with aforementioned -al option to see what the compiler generates and try to pick things up from that. QuoteHrnf,, I can declare .byte and set my name.. hoping  that setting .word(s) would do the trick for the orthers .. But! They aren't zeroed. How can that be? I believe it depends on the section wherein the declaration is made. QuoteAlso in the global variable scenario it seems like setting the  integers to = 0 in the "var" section has no effect. The generated asm from a pure pascal program uses the (intermediate) symbol name to access the global variable. PS: in the file you mentioned, do note the ifdefs to indicate thumb- mode else it uses default compiler mode. PPS: also note the available modifiers that can be used for a function/procedure: https://www.freepascal.org/docs- html/current/ref/refse100.html#refsu85.html ---------------------------------------------------------------------- micken · 2023-08-03 13:15 The asm bit is solved. Made a couple of routines and did the reset in pascal. However it fails more or less directly in heaplist management. Addresses returned seems ok. So dunno. looks like this: ( I don't know about the public alias,, string needed to be on one line, maybe it isn't needed) Code: [Select]Function Fprocreada(len:size_t):Integer;assembler;[public, alias:'ROFPC_CRDA']; asm   stmfd sp!,{r3-r9}   mov r2,r0   mov r0,#0   mov r4,#0   mov r6,#0   ldr r1,=0xffffffff   ldr r3,=0xffffffff   ldr r5,=1024*1024*1024   ldr r7,=0xffffffff   adr r8,.Lnamstr   swi #0x66   mov r0,r1   b .Lcredaexit .Lnamstr:   .byte "f","p","c",0 .Lcredaexit:   ldmfd sp!,{r3-r9} end; Function Fprochdea(len:size_t;da:Integer):Integer;assembler;[public,al ias:'CHDA']; asm   mov r2,r1   mov r1,r0   mov r0,r2   swi #0x2a   mov r0,#0 end; Function Fprogetda(da:Integer):longword;assembler;[public,alias:'SYSC_GETDA']; asm   mov r1,r0   mov r0,#2   swi #0x66   mov r0,r3 end; Function Fprommap(len:size_t):longword;  [public, alias : 'ROFPC_SYSC_MMAP']; var   localsz: Integer; begin if dynx=0 then   begin   dynx:=1;   dynno:=Fprocreada(len);   Writeln('dacreate');   Writeln(dynno);   dynsz:=len;   dynad:=Fprogetda(dynno);   Writeln(dynad);   dynsz:=len;   end else   begin   Writeln('chda');   Fprochdea(dynno,len);   {dynad:=Fprogetda(dynno);}   dynad:=dynad+dynsz;   dynsz:=dynsz+len;   end;   Writeln('dyn return');   Writeln(dynad);   result:=dynad; end; ---------------------------------------------------------------------- micken · 2023-08-03 13:33 I get a printout that I don't know where it comes from, not added by me I think.I might have enabled debug options , but it just prints the address(?). All well until right before crash where the number probably is a result of variable overflow(?). It is negative. What kind of addresses can heap manager cope with? Before when used the other alloc method the addresses was (much) smaller. As it is now they requires at least longint. EDIT! Sanity check! I reseted heap.inc and now things move a bit better. Probably one of my prints affected something ---------------------------------------------------------------------- micken · 2023-08-03 16:49 I have switched back to old mem alloc .. it worked after all. I have tried ( as suggested ) running cross compiler show the files it opens. It is very different from my native compiler.. first it opens the error ( message ) file. After that it opens hellopas.pp. why is that? The argument is hellopas.pas. Ehem.. sorry my argument was hellopas , hence the strange behavior. And there it stops , bails out in heap manager. I think there are connections to what the compiler tries to open and the errors, rather than blaming  alloc. The problem with arguments is that it sort of not working with elf files.. in theory r0 argc r1 argv but I haven't got that working yet ( not tried much). In riscos native binaries you run a swi to get args. So right now args are hard coded. I added "-va" now , and that worked. The last message is "registering new unit system". Right after that it should print about system unit, and eventually search for it. But that doesn't happen. ---------------------------------------------------------------------- micken · 2023-08-04 08:38 I did a simple ram test: Array of 5M that I filled. No problem. But is array allocated inside of executable? Doesn't look that way. I also did GetMem with 5 megs. ---------------------------------------------------------------------- TRon · 2023-08-04 10:40 Quote from: micken on August 04, 2023, 10:38:49 amBut is array allocated inside of executable? Doesn't look that way. Yes, no, depends  If you declare a variable as a static array it will be stored in the bss section (see https://en.wikipedia.org/wiki/.bss) If you declare a variable as a dynamic array it will (initially) be stored as a pointer. If you then set the length of the array it will allocate the memory. if you declare a variable/constant as a static  array with values it will be stored in a .data section (see: https://en.wikipedia.org/wiki/Data_segment) First 2 variants do not physically 'store' (the contents) of the array in your executable but are (become) part of it. That is usually how operating systems work (memory protection etc so that other processes/tasks can not access the memory from your executable). The 3th variant does physically store the contents of the array , but in a special data section. I understand that this might not be applicable to riscos (it doesn't for Amiga/AROS/MorphOS/Spectrum/msdos/etc either) but in basics that is how such things work in nowadays operating systems. fwiw: it is part of how an object file is structured. There are assemblers that can do it differently (most adhere to these conventions though) but they are usually custom assemblers/linkers (e.g.not supported by fpc unless support is (manually) added). ---------------------------------------------------------------------- micken · 2023-08-04 11:12 Thanks for the clarification of array . The GetMem version allocated ram and write to it without issue. I have made a serious debug attempt (without debugger ) The screenshot screenshot shows disasembly and regs/memory dump. The actual error is at 0x2a740 (relative to application). It does a store to R0. From the register dump you can see that R0 points to a invalid address, and the memory dump confirms this. https://github.com/fpc/FPCSource/blob/main/rtl/inc/heap.inc#L989 I think that this works in most cases. So the question is where does that bad address come from? Can't the variable not hold it? The Alloc function returns valid addresses all the time. I am running out of ideas ---------------------------------------------------------------------- TRon · 2023-08-04 12:05 Quote from: micken on August 04, 2023, 01:12:15 pmI am running out of ideas I can see the error but have no idea whatsoever. Unfortunately I am not familiar with fpc heap internals to be of any help there :-S. Sorry for that. Perhaps a more seasoned developer is able to provide a hint (or two) ? ---------------------------------------------------------------------- micken · 2023-08-04 12:08 Quote from: TRon on August 04, 2023, 02:05:35 pmQuote from: micken on August 04, 2023, 01:12:15 pmI am running out of ideas I can see the error but have no idea whatsoever. Unfortunately I am not familiar with fpc heap internals to be of any help there :-S. Sorry for that. Perhaps a more seasoned developer is able to provide a hint (or two) ? I found it!! It is a path that refuse to be find .. and it loops .. each time with a new address. So at some point it hits the slot right after current region.I just need to find where it does that and ifdef it out. ---------------------------------------------------------------------- TRon · 2023-08-04 12:12 Quote from: micken on August 04, 2023, 02:08:00 pmI found it!! It is a path that refuse to be find .. and it loops .. each time with a new address. So at some point it hits the slot right after current region.I just need to find where it does that and ifdef it out. Just for the record and afaik: you should not have to manually mess with these routines as long as the basic routines on which the FPC implementation depends on are present (and are working as intended/advertised). edit: That basically (and afaik) means correct working riscos implementations for memory and i/o related functionality plus some other setup you wish to do (for example Amiga target has a custom filehandle list that automatically closes filehandles that where previously opened and forgotten to be closed). ---------------------------------------------------------------------- micken · 2023-08-04 12:14 Quote from: TRon on August 04, 2023, 02:12:05 pmQuote from: micken on August 04, 2023, 02:08:00 pmI found it!! It is a path that refuse to be find .. and it loops .. each time with a new address. So at some point it hits the slot right after current region.I just need to find where it does that and ifdef it out. Just for the record and afaik: you should not have to manually mess with these routines as long as the basic routines on which the FPC implementation depends on are present (and are working as intended/advertised). Sure , understand. I am just curious how I can stop it from searching system directories or at least stop when it thinks they cannot be found.. got to be somewhere in the platform specific files.. Good to know when doing a proper target. ---------------------------------------------------------------------- TRon · 2023-08-04 12:30 Quote from: micken on August 04, 2023, 02:14:11 pmSure , understand. I am just curious how I can stop it from searching system directories or at least stop when it thinks they cannot be found.. got to be somewhere in the platform specific files.. Good to know when doing a proper target. So, is it safe to conclude it is originating from some file related routine that does not properly return the correct return value so that it keep on trying to locate the same file/dir over and over ? If so then perhaps have a look at the findfirst/findnext implementations (sysutils). edit: forgot to mention fileexists, directoryexists, or actually all file io routines from that unit and for good measure all filename related routines PS: And.. I do not know about unit dos. I take it that it is only used when writing TP compatible programs (thus not used by current compiler code). ---------------------------------------------------------------------- PascalDragon · 2023-08-04 19:07 Quote from: TRon on August 03, 2023, 11:31:36 amQuote from: micken on August 02, 2023, 11:03:59 pmIn the asm help page I get a x86 example and that use data transfer from variable. Unfortunately the use(age) of (inline) assembler is poorly documented and in case there is something it is (mostly) oriented at intel. The ARM inline assembler is based on the official ARMASM. Quote from: TRon on August 04, 2023, 02:30:14 pmedit: forgot to mention fileexists, directoryexists, or actually all file io routines from that unit and for good measure all filename related routines These are indeed very important for searching for files in both the RTL as a whole and the compiler especially. Quote from: TRon on August 04, 2023, 02:30:14 pmPS: And.. I do not know about unit dos. I take it that it is only used when writing TP compatible programs (thus not used by current compiler code). The Dos unit is indeed not relevant for the compiler. Porting it can be ignored at first. ---------------------------------------------------------------------- TRon · 2023-08-06 11:39 Thank you very much for the confirmation(s) PascalDragon. To one that knows: Is there (any) documentation for the usage on implicitunits use in fpc makefiles (without resorting to analyze the actual implementation) ? For instance, is there a bare minimum that has to be obeyed (or something to that extend) ? it is currently unclear to me if it is at all required to declare it.  The aim is to get by using/requiring as less dependencies as possible. I was able to find information on pretty much the other available fpcmake file settings. ---------------------------------------------------------------------- micken · 2023-08-08 15:42 Status: I did some more work with the swi callers. If I bypass the error related to not having the last expected slot in freelist I get to the point that it loads and processes system.ppu. It prints a lot of sourcecode files that it doesn't find, maybe that isn't an issue. But, heap management is still broken. It feels like above, it doesn't alloc the right amount of slots. It can  be alignment , but I doubt that, Although.. I am a bit worried, it seems like it expects a continues allocated ram. I don't have that. It adds something (28 in my case) to the first address. Since the libc version uses malloc() I guess my method should work. IS there a flag somewhere about this? Seems like osheap.inc is something I want to use. Is that possible? ---------------------------------------------------------------------- TRon · 2023-08-08 17:17 Thank you for the update micken. Quote from: micken on August 08, 2023, 05:42:36 pmIt prints a lot of sourcecode files that it doesn't find, maybe that isn't an issue. The list can be extensive and the only source-code files it really needs to be able to find are those that needs/require compilation (usually files that are directly part of your project). Most standard units such as classes, sysutils, etc are precompiled and only require the source-code (for recompilation) when the checksum does not match. Recompilation of precompiled units is something that an ordinary user will not run into though it does happen on more frequent when trying to compile a (3th party) package. QuoteI am a bit worried, it seems like it expects a continues allocated ram. I don't have that. Not sure if I understand that remark correctly: your (riscos) memory allocation routine is only capable of returning a memory pool ? QuoteIt adds something (28 in my case) to the first address. Since the libc version uses malloc() I guess my method should work. IS there a flag somewhere about this? Yes, if libc is capable then you should be able to as well. About the flag: I am not sure what you meant there. A flag for using libc or a flag about allocting memory in pools or continues memory ? In case the former, then yes. It is a compiler option (sorry as the name eludes me atm). QuoteBut, heap management is still broken. It feels like above, it doesn't alloc the right amount of slots. It can  be alignment , but I doubt that, Have you made some simple tests that allocates/free/uses memory ? (for a small example see also: https://www.freepascal.org/docs- html/rtl/system/freemem.html). Note that (almost) all memory related routines (https://www.freepascal.org/docs-html/rtl/system/memoryfunctions.html) are required to be implemented and work properly for the heap/stack to work as intended (you can ignore the old dos style routines). Sorry as I can't really help pinpointing the issue for you it as it is simply above my understanding (though, the theory behind it is simple enough). As stated earlier you normally do not have to touch any of that code. That also means that the origin for your error is located somewhere else (but as you discovered the heap routines are buried deep into the RTL and are the last (most basic) routines to be called when running code). So you would have the need for help from someone that understands the heap related implementations in and out and even then I doubt such a person is able to help you out to pinpoint the origin for you issue (but i might be wrong about that). fwiw: I am still busy with other things so am still unable to fully dedicate my time to this project (but I will, or at least try  ). ---------------------------------------------------------------------- micken · 2023-08-08 19:12 About memory: 1) have a malloc styled routine which seems to work fine. 2) rtl/inc/heap,inc blows up when a "slot" isn't connected to a valid address. I can bypass this.. but in the end it will crash sooner or later. 3) If this is supposed to work with "c" malloc ,I don't know why it doesn't work now. 4) I have found a osheap.inc , and wonders how that works. Seems like something that could be useful. I am still using linux/unix rtl. In sysheap in rtl/unix there areen't a lot of routines to implement, ---------------------------------------------------------------------- TRon · 2023-08-09 08:32 Quote from: micken on August 08, 2023, 09:12:52 pm2) rtl/inc/heap,inc blows up when a "slot" isn't connected to a valid address. I can bypass this.. but in the end it will crash sooner or later. Yeah, I understand. And with the risk of sounding like a broken record, the problem is that something like that should not occur in the first place (ofc. unless there is a bug in the actual heap implementation which is, imho, not very likely). There must be something amiss in some of the basic functionality but have no idea what that might be (not even a clue where to look for). Quote3) If this is supposed to work with "c" malloc ,I don't know why it doesn't work now. As stated before, unfortunately atm me neither. There is some (little) documentation on heap that can be found here (https://www.freepascal.org/docs- html/prog/progse34.html#progsu173.html) and in particular an example for using c functionality for implementing a custom memory manager (https://www.freepascal.org/docs- html/prog/progsu174.html#x220-2340008.4.4). That works as intended as it is common to use unit cmem (https://www.freepascal.org/docs-html/rtl/cmem/index.html) for platforms that support it. I have no idea if there are tests available for testing the heap implementation. Quote4) I have found a osheap.inc , and wonders how that works. Seems like something that could be useful. It is useful. However (and unfortunately), if your aim is to use it to build/run the compiler native then you are out of luck as the compiler itself does not have any proficiency to support osheap.inc. It is noted in the source-code of osheap.inc that the implementation has its limitations. Should be fine for cross-compiling simple programs though. I understand this to perhaps be frustrating for you atm but I honestly and unfortunately can't help you with this particular issue. fwiw: This forum is not really the place where core devs communicate as they only drop by on occasion so you might want to have a look at the mailinglist (https://lists.freepascal.org/mailman/listinfo) though for this particular issue it is my understanding that one of the core devs already stated to put the effort in cross-compilation instead of trying to run the compiler native. which imho is indeed the natural flow of things. ---------------------------------------------------------------------- micken · 2023-08-09 15:13 Quotethe effort in cross-compilation instead of trying to run the compiler native. which imho is indeed the natural flow of things. I am doing that ,but applies the results to native compiler. I have come pretty far , by, as a temporary fix, alloced new ram for slots that points to void. The compiler starts to parse the source file. It sees "begin" and goes on. However for some reason it puts "program hello;" into next line. Just before the error the compiler does a ioctl. As far as I can see , ioctls is only used for terminal handling. But it would be good to know where and why it is called. I did a call trace some days ago with HandleError(num) ,very easy, but I have completely forgot the error number. Maybe someone knows? ---------------------------------------------------------------------- micken · 2023-08-10 09:26 I have a working compiler!! I need to link manually , should be easy to start ld from compiler. Small output glitch from hello world (output from prt0, could be removed), but the string is printed with no crash! ---------------------------------------------------------------------- TRon · 2023-08-10 10:01 Quote from: micken on August 10, 2023, 11:26:37 amI have a working compiler!! Nice ! Thank you for your extensive labour and great achievement. ---------------------------------------------------------------------- micken · 2023-08-10 10:34 Heap management hack is still in. I leave that to whoever want to make a proper target. I am going to share my source tree asap. There is also problems with arguments. The riscos way doesn't work well with elf files. It should be regs containing argc/argv , but I haven't managed to make it work. ---------------------------------------------------------------------- TRon · 2023-08-10 10:44 Quote from: micken on August 10, 2023, 12:34:22 pmHeap management hack is still in. I leave that to whoever want to make a proper target. QuoteI am going to share my source tree asap. That would very much be appreciated. QuoteThere is also problems with arguments. The riscos way doesn't work well with elf files. It should be regs containing argc/argv , but I haven't managed to make it work. If the 'normal' startup code that the OS uses to execute a program does not include/contain any (predefined values in) registers (of noticeable importance) but it is possible to get a list of arguments by other means provided by the OS then that is workable as well. There are more platforms that do not provide argc/argv in registers. Sometimes important pointers/values are situated on the stack or can be obtained by calling some OS functionality. Sometimes that does not even resemble argc/argv/envp as that is mostly originating from c. The argv/argc/envp variables can be constructed at startup in such cases. e.g in one of your previous posts you mentioned OS_GetEnv which seems capable enough to do the job. ---------------------------------------------------------------------- micken · 2023-08-10 11:40 Quote OS_GetEnv which seems capable enough to do the job. Which doesn't work if !gcc has been seen and probably not good enough anyway. ---------------------------------------------------------------------- TRon · 2023-08-10 11:56 Quote from: micken on August 10, 2023, 01:40:32 pmWhich doesn't work if !gcc has been seen and probably not good enough anyway. My only guidance atm is the (existing) documentation. So if there is any behaviour that differs from what is documented then I would have no clue (I simply lack the experience). According to the docs: QuoteThe values in R0-R2 are only guaranteed to persist until the next program is run and so this call should be used at the start of a program and always before the first Wimp_Poll. Which indicates to me that as long as I make copy of the contents that RO points to, I do have a copy of the command-line which can be dissected into (something compatible to) argv and argc (using pascal code). I am especially intrigued by your remark "Which doesn't work if !gcc has been seen". Could you elaborate on that ? ---------------------------------------------------------------------- micken · 2023-08-10 12:02 QuoteWhich indicates to me that as long as I make copy of the contents that RO points to, I do have a copy of the command-line which can be dissected into (something compatible to) argv and argc (using pascal code). I am especially intrigued by your remark "Which doesn't work if !gcc has been seen". Could you elaborate on that ? Yes R0 and so on should provide the info needed ( but OS_GetEnv is still needed for stack location) GCC loads a module that prevents the argument thing to stop working , just giving you the program name. There are probably more issues, more programs that will cause this. ---------------------------------------------------------------------- TRon · 2023-08-10 12:22 Quote from: micken on August 10, 2023, 02:02:20 pmGCC loads a module that prevents the argument thing to stop working , just giving you the program name. There are probably more issues, more programs that will cause this. Ok, so the behaviour is inconsistent depending on what programs are run (before and after our FPC code I assume). Any alternatives ? an environment variable that contains the cmdline or list of parameters ? How do other programs that rely on the existent/presence of parameters handle such a situation ? Ofc. I can come up with alternatives such as using a file that "passes" parameters but in such a case there would also have to be a separate loader provided by the OS (or one of available modules) itself. I was looking for the somanager implementation (values pushed to stack or stored in registers before calling the main entry-point) in the source-tree but so far was unable to locate it. Perhaps that might be of assistance ? ( ---------------------------------------------------------------------- TRon · 2023-08-10 17:21 AH, sorry micken. I just stumbled upon your thread. I have a look later at the links that were posted. Awaiting with you on the results from your question 4 hours ago ---------------------------------------------------------------------- micken · 2023-08-10 19:57 I managed to convert the elf file to aif now. This will enable OS_GetEnv to work , I hope. At least for the compiler.. it will still generate elf files. I am not doing more now , for a couple of days. But I am very happy that many hours of work actually realized a compiler! ---------------------------------------------------------------------- TRon · 2023-08-11 06:57 Quote from: micken on August 10, 2023, 09:57:15 pmI managed to convert the elf file to aif now. This will enable OS_GetEnv to work , I hope. At least for the compiler.. it will still generate elf files. In your opinion does that mean that it would be preferable to have the aif converter part (perhaps optional) of the compilation process (when not using libc) ? I do not know how the core devs feel about it though (and atm I have no idea if I can integrate it without disturbing the normal flow, we'll have to see if that works out). QuoteI am not doing more now , for a couple of days. But I am very happy that many hours of work actually realized a compiler! No problem. You have done an important step: a proof of concept so that we know it is possible. It would be nice if it would be possible to pick your brain when it comes to it. Thank you again for all your efforts. ---------------------------------------------------------------------- marcov · 2023-08-11 07:16 Quote from: TRon on August 11, 2023, 08:57:53 amQuote from: micken on August 10, 2023, 09:57:15 pmI managed to convert the elf file to aif now. This will enable OS_GetEnv to work , I hope. At least for the compiler.. it will still generate elf files. In your opinion does that mean that it would be preferable to have the aif converter part (perhaps optional) of the compilation process (when not using libc) ? I do not know how the core devs feel about it though (and atm I have no idea if I can integrate it without disturbing the normal flow, we'll have to see if that works out). There is a target specific bit that governs calling external utils like assembler, linker and additional tools.  For Linux that is t_linux etc.  Such target specific files are in compilers/systems.  The i_ files are records with target specific information and flags, the t_ files are objects that govern calling externals. Probably you'll need a t_riscos there. (that you can initially copy from whatever system you use now) ---------------------------------------------------------------------- TRon · 2023-08-11 07:19 Quote from: marcov on August 11, 2023, 09:16:14 amProbably you'll need a t_riscos there. (that you can initially copy from whatever system you use now) Yeah, I got that in place. I just was not sure if I am at liberty to do there whatever I please though  Thank you for the pointers marcov. ---------------------------------------------------------------------- micken · 2023-08-13 10:28 Hello everyone! I have created a binary distribution that I like to share. It would be good with blackbox testing. How to use: Download rpcemu with RISC OS Direct: https://www.marutan.net/rpcemu/easystart.html Download fpc.zip: http://micken.se/pix/fpc.zip Extract rpcemu copy fpc.zip to $rpcemu/hostfs start rpcemu left click on the hostfs icon (iconbar to the left) Find the file fpc/zip middle click on it to get a menu. Find the item .. file or dir fpc/zip. open the submenu goto type enter "archive" Now double click on fpc/zip. drag the fpc directory from the archive window to the HostFS icon click on HostFS icon open fpc directory It contains a bunch of files: The files ending with 'o' are object files. "ppcarm" is the compiler. Middle click in the fpc directory window. Select "Set directory" click on the icon on the right hand of iconbar. That will give you a window called tasks. Find a red bar named Next. Drag that box to the right and increase it to at least 16megs. press ctrl-f12 This will give you a taskwinow type ppcarm hello.pas This will end with a linker error. open the directory "hello" A file "o" can hopefully be found .. drag it to the fpc window Find !gcc in hostfs.$.programming.c (hostfs/programming/c/. double click on !gcc go back to taskwindow type: ld prt0o sys]"]>Blocked o -o helloexe This will link your little program run it with "helloexe" inside taskwindow. With a bit of luck you will se Hello World! Good luck! press ctrl-f12 ,, this will open a taskwindow. ---------------------------------------------------------------------- micken · 2023-08-13 14:36 Do not be tempted to upgrade !SharedLibs.. that makes all elf files generated with fpc to cause a "branch through zero" errors. However with a bit of hack you can make the elf to aif. This is what I did with the compiler executable. 1, change the second word of the elf file to: 0x61010101 2, run "elf2aif infile outfile" , tool included in !GCC. ---------------------------------------------------------------------- StefanRISCOS · 2023-08-13 16:29 @Micken Thanks for your efforts! I didn't try yet but downloaded the zip. ---------------------------------------------------------------------- micken · 2023-08-13 19:11 A little basic program to help the patching: Extract in riscos usage: elfpatcher exename exename is the output of "ld" elfpatcher will patch the second word in elf and then convert it to aif Filename of aif file is "exename/aif" You need to double click on !GCC first in order to have access to elf2aif, which this program uses. ---------------------------------------------------------------------- micken · 2023-08-13 19:16 No guarantee that any of shared stuff works!  So emulator is best , if something blows up! ---------------------------------------------------------------------- StefanRISCOS · 2023-08-13 21:46 Just a side question as you were talking about memory allocation libraries: What do you think about Paolo's Z-Vector library? Might that help or is it unrelated and more additional feature? https://github.com/pzaino/zvector#zvector ---------------------------------------------------------------------- micken · 2023-08-13 22:20 Quote from: StefanRISCOS on August 13, 2023, 11:46:52 pmJust a side question as you were talking about memory allocation libraries: What do you think about Paolo's Z-Vector library? Might that help or is it unrelated and more additional feature? https://github.com/pzaino/zvector#zvector It is for C and use malloc(). ---------------------------------------------------------------------- micken · 2023-08-14 10:27 I want to have a swidispatcher function.. In C we have _kernel_swi. I propose something like this: Compiled and tested on riscos! Code: [Select]asmstr : String; function  runswi (rr0:Pointer;rr1:word;rr2,rr3,rr4,rr5,nr:word):Integer;assembler;   asm         stmfd sp!,{r4}         adr r4,.Laa         ldr r1,nr         strh r1,[r4] .Laa:   .word 0x0         .byte 0x0,0xef         ldmfd sp!,{r4}   end; asmstr:='Helloasm';   runswi(@asmstr,0,0,0,0,0,2); I also found a very annoying bug! If I add a procedure above the program code I get a abort. If after no problem. Functions works. EDIT: procedure works just fine, it failed when I used asm in it. EDIT2: The routine needs to be called with longword and not pointer since it is up to the swi to decide if a reg value is a pointer or not The call looks like this: Code: [Select]asmstr:='Helloasm';   runswi(longword(@asmstr),0,0,0,0,0,2);   c:='x';   runswi(longword(c),0,0,0,0,0,0); SWI #2 is print string pointed by r0 , SWI #0 is print char in r0. This can be useful when building libraries for accessing riscos features. Should be the only bit asm needed. However calling function needs to be able to update register variables since a swi usually returns more than one value. ---------------------------------------------------------------------- micken · 2023-08-14 12:37 PM me for source archive. Please don't bash me because of hacks. I am very aware of that it can't be done this way. It is a proof of concept , nothing more. ---------------------------------------------------------------------- micken · 2023-08-14 13:33 So with regs in/out can look like this.. The r0 is set from the array , so first parameter is not used. Returns "4" in the fictive "r6" in arry. :: Code: [Select]program roswitest; var   i : Integer;   c : Char;   asmstr : String;   regarr: array[0..9] of longword; function  runswi (rr0:longword;rr1:word;rr2,rr3,rr4:longword;regarr:Po inter;nr:word):Integer;assembler;   asm         stmfd sp!,{r4,r7,r8}         adr r4,.Laa         ldr r1,nr         ldr r8,regarr         ldr r0,[r8]         strh r1,[r4] .Laa:   .word 0x0         .byte 0x0,0xef         mov r7,#4         ldr r8,regarr         str r7,[r8,#4*6]         ldmfd sp!,{r4,r7,r8}   end; begin Writeln('Hello from fpc/riscos: SWI test!');   asmstr:='Helloasm';   regarr[0]:=longword(@asmstr);   runswi(longword(@asmstr),0,0,0,0,@regarr,2);   c:='x';   regarr[0]:=longword(c);   runswi(longword(c),0,0,0,0,@regarr,0);   Writeln('return:');   Writeln(regarr[6]); end. ---------------------------------------------------------------------- micken · 2023-08-14 15:54 So ... things are working nicely. I have done a Wimp App with pascal. It doesn't do much , but have the obligatory WiMP polling loop and can be quit using taskmanager. You can see it in Tasks window (PascalWimp) and the source code. Screenshot attached. ---------------------------------------------------------------------- micken · 2023-08-14 22:02 And a window opens: I am doing the same thing as it would be done in BASIC. It needs to be a library. For general use it should be possible to simplify a bit , assuming some things. ---------------------------------------------------------------------- micken · 2023-08-14 23:09 The whole program. Code: [Select]program roswitest; var   i : Integer;   c : Char;   asmstr: PChar;   regarr: array[0..9] of longword;   wimp: array[0..100] of longint;   wimpquit: Integer;   taskh: longword;   wh: longword;   wtitle: string; function  runswi (rr0:longword;rr1:word;rr2,rr3,rr4:longword;regarr:Po inter;nr:longword):Integer;assembler;   asm   stmfd sp!,{r4,r7,r8} adr r4,.Laa ldr r1,nr strb r1,[r4] mov r2,r1,lsr #8 strb r2,[r4,#1] mov r2,r1,lsr #16 strb r2,[r4,#2] ldr r8,regarr ldr r0,[r8] add r8,r8,#4 ldr r1,[r8] add r8,r8,#4 ldr r2,[r8] add r8,r8,#4 ldr r3,[r8] .Laa: .byte 0x0,0x0,0x0,0xef mov r7,#4 ldr r8,regarr str r0,[r8] str r1,[r8,#4] str  r2,[r8,#8] str r3,[r8,#12] ldmfd sp!,{r4,r7,r8}   end; begin   wimpquit:=0;   regarr[0]:=310;   regarr[1]:=$4b534154;   asmstr:='PascalWimp';   wtitle:='PascalWindow'#0;   regarr[2]:=longword(asmstr);   regarr[3]:=0;   runswi(0,0,0,0,0,@regarr,$400c0);   taskh:=regarr[1];    wimp[0]:=0;    wimp[1]:=0;    wimp[2]:=530;    wimp[3]:=140;    wimp[4]:=0;    wimp[5]:=0;    wimp[6]:=-1;    wimp[7]:=longword(%10000110000000000011000000010010);    wimp[8]:=$01070207;    wimp[9]:=$000c0103;    wimp[10]:=0  ;    wimp[11]:=-140;    wimp[12]:=530 ;    wimp[13]:=0   ;    wimp[14]:=$27<<24 or %100111101;    wimp[15]:= 0 ;    wimp[16]:=1 ;    wimp[17]:= 0;    wimp[18]:=longword(asmstr);    wimp[19]:=-1;    wimp[20]:=10;    wimp[21]:=0 ;   regarr[1]:=longword(@wimp);   runswi(0,0,0,0,0,@regarr,$400c1);   wh:= regarr[0];    wimp[0]:=wh;    wimp[1]:=0;    wimp[2]:=0;    wimp[3]:=1920*2;    wimp[4]:=1080*2;    wimp[5]:=-1;   regarr[1]:=longword(@wimp);   runswi(0,0,0,0,0,@regarr,$400c5);   while wimpquit=0  do   begin   regarr[0]:=%11100000110001;   regarr[1]:=longword(@wimp);   runswi(0,0,0,0,0,@regarr,$400c7);   if regarr[0]=17 then   if wimp[4]=0 then wimpquit:=1;   if regarr[0]=18 then   if wimp[4]=0 then wimpquit:=1;   if regarr[0]=2 then   begin   regarr[1]:=longword(@wimp);   runswi(0,0,0,0,0,@regarr,$400c5); end;   if regarr[0]=3 then   begin   wimpquit:=1;   end;   end;   regarr[0]:=taskh;   regarr[1]:=$4b534154;   runswi(0,0,0,0,0,@regarr,$400dd); end. ---------------------------------------------------------------------- TRon · 2023-08-15 04:25 Quote from: micken on August 14, 2023, 12:27:27 pmI want to have a swidispatcher function.. In C we have _kernel_swi. I propose something like this: Something like that is available in rtl/linux/arm/syscall.inc named FpSysCall (with overloads for different parameters, and using nostackframe). If possible it would be better to re-use those for consistency. Also note the call to seterrno which sets a systemwide error number. PS: the wimp list in the roswitest example looks a lot like some form of a taglist. Is there documentation on/for that ? (I was not able to locate it on short notice). It might be that such a list is easier to accomplish (for the enduser) than you are doing right now. edit: Found it just after I posted. It is WIMP_CreateWindow with a window block. Normally we use (packed) records to store such kind of information. See for example record TWindow for Amiga. PPS: I've (briefly) tried your zipped compiler but got a bit stuck in that the taskwindow is telling me that it is busy and can't run ppcarm. Note that I did not follow your instructions literally  for the unpacking bits (I did that on the host) but followed your instructions from there on. ---------------------------------------------------------------------- micken · 2023-08-15 05:34 QuoteSomething like that is available in rtl/linux/arm/syscall.inc named FpSysCall (with overloads for different parameters, and using nostackframe). If possible it would be better to re-use those for consistency. Also note the call to seterrno which sets a systemwide error number. As far as I can see Linux syscalls doesn't return information in a lot of registers.. which is the case for many swi's on riscos. You also need to know that riscos swi is called with swi #number and number is unique for every call. _kernel_swi works like the above ( the last example ). You pass a pointer to register arrays ( probably can be be done with records). and at the end writes back the registers. Also note the self modifying part. Somehow the swi number needs to be passed in. It isn't in a register it is just in the same word as the instruction ( simplified ). So again different than the linux way , where it just calls swi #0 with syscall number in regs. Needles to say: My syscalls.inc is a empty shell.  If it is possible to access packed records by knowing the size of each field it might work ( they need to be longint/longword. Otherwise you are going to need different functions ( with asm ) for each swi.  The swifunction should be used in the riscsos target rtl. Right now I have different asm functions for each swi needed, which is a bad way. Quotebits (I did that on the host) but followed your instructions from there on. That gives you files without file types. It will not work. BTW. I recommend using the "elfpatcher" tool. It will give you a proper native executable which makes stuff to work without a old elf loader. Put it in !Boot.Library, the easiest way to have it global accessible. ---------------------------------------------------------------------- TRon · 2023-08-15 06:11 Quote from: micken on August 15, 2023, 07:34:41 amAs far as I can see Linux syscalls doesn't return information in a lot of registers.. which is the case for many swi's on riscos. Seems that way, yes. QuoteYou also need to know that riscos swi is called with swi #number and number is unique for every call. _kernel_swi works like the above ( the last example ). You pass a pointer to register arrays ( probably can be be done with records). and at the end writes back the registers. Also note the self modifying part. Somehow the swi number needs to be passed in. It isn't in a register it is just in the same word as the instruction ( simplified ). So again different than the linux way , where it just calls swi #0 with syscall number in regs. Drats you are right on the last part there, and I overlooked that. Apologies. Ok, in that case it requires some additional thoughts. QuoteNeedles to say: My syscalls.inc is a empty shell.  Yeah, it like that for me as well atm QuoteIf it is possible to access packed records by knowing the size of each field it might work ( they need to be longint/longword. Otherwise you are going to need different functions ( with asm ) for each swi.  The swifunction should be used in the riscsos target rtl. Right now I have different asm functions for each swi needed, which is a bad way. Obtaining the size of a field is not a problem. SizeOf(recordname.fieldname) to get the size of the field in bytes. That can be the declared record or you can use the record type definition (e.g. TRecordName.FieldName). I did notice, for example in the window block that  "Title foreground and window frame colour", "Title background colour" as well as others have a different size. In your example you combined them into a longword but that is not required as you can pass the pointer to the record just as you did with "regarr[1]:=longword(@wimp);" and the compiler will be none the wiser as long as the record fields are aligned correctly (hence the packed record type that makes sure it it does not align the individual fields). thus, for example: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i type  // ricos gcc probably has some nice header files with these structures that we could copy-paste in order to have consistent field names between the languages.  PWIMPWIndow = ^TWIMPWIndow;  TWIMPWIndow = packed record    minx, miny, maxx, maxy : longword;    scrollx, scrolly: longword;    location: longword;   Flags: Longword;    fg_and_frame_colour: byte;    etc...  end; var  WIMPWindow: TWIMPWindow; begin  // can do it this way  WIMPWindow.Flags := %01010101;   // or using with to avoid using the name of the variable /and/ the fieldname  with WIMPWindow do  begin    minx := 0;    miny := 0;    etc...   end;  ...  regarr[1]:= longword(@WIMPWindow);  ...end.  fwiw: if in the end it turns out that it is not possible to create a uniform way to call swi's then it is also possible to add them all manually by their respective names. Note that multiple values can be returned by using: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i function example(input: number; var output1: longword; var output2: word; var output3: byte): longint;begin  writeln('input = ', input);  output1 := $FFFFFFFF;  output2 := $FFFF;  output3 := $FF;  result := -1;end;  So you do have options other than just relying on the return value. Although you could make the return value an array or pointer to a list of values as well. Actually for only output the parameters should actually be out (output) instead of var as var is a bit ubiquitous usage that way. QuoteThat gives you files without file types. It will not work. Ah, I already suspected something like that to be the case. Thank you for the confirmation. ---------------------------------------------------------------------- micken · 2023-08-15 06:17 QuoteNote that multiple values can be returned by using: You still need to get the return values from registers, which is different for each swi But I might uneducated, maybe your way works.. ( I would say that it still need a register array pointer, setting registers to arguments, which is fine in a library function. You still need the runswi at the lowest level. QuoteI did notice, for example in the window block that  "Title foreground and window frame colour", "Title background colour" as well as others have a different size. In your example you combined them into a That is true. But in the end , most of riscos blocks are 4 bytes for each field. ---------------------------------------------------------------------- TRon · 2023-08-15 06:24 Quote from: micken on August 15, 2023, 08:17:43 amQuoteNote that multiple values can be returned by using: You still need to get the return values from registers, which is different for each swi But I might uneducated, maybe your way works.. ( I would say that it still need a register array pointer, setting registers to arguments, which is fine in a library function. You still need the runswi at the lowest level. Nah, I am the uneducated one. The problem is that right now I can't see the trees in the forest. There might be some consistent use of (amount of) return registers, the same as that there could be for input (I would have to check each and every swi call for that). If you are able to come up with something that works for you in a consistent and uniform way (for as far as possible) then please go with that for now and not waste too much time on declaring/translating each and every swi call right now (just what you need/want for these nice examples that you are sharing with us). ---------------------------------------------------------------------- micken · 2023-08-15 06:31 Quote If you are able to come up with something that works for you in a consistent and uniform way (for as far as possible) then please go with that for now and not waste too much time on declaring/translating each and every swi call right now. I leave rtl bits to you... I can provide you with a list of swi's you need to map to the rtl functions. About elfs and aifs .. I can run my aif with less than 1meg next slot. You need 5 for elf ( if I remember right). My window example uses 280K ram for the executable. It still allocates ram from module area. Ehem wrong. I compared elfs with aif , they are the same. Although elf needed twice the next slot. ---------------------------------------------------------------------- TRon · 2023-08-15 06:38 Quote from: micken on August 15, 2023, 08:31:29 amI leave rtl bits to you... I can provide you with a list of swi's you need to map to the rtl functions. That's ok to leave that to me. Would be greatly appreciated if you could provide a list. Come to think of it,the swi calls seem to be separated in different groups when browsing to the documentations so in that regards there isn't any difference with specific units that fall into a particular category (just as libraries/libraryheaders do). ---------------------------------------------------------------------- micken · 2023-08-15 06:47 I just tried my pascal generated executable converted to aif. It worked on a 8meg ram system. riscos 5.x leaves me with 1m free after boot up ---------------------------------------------------------------------- micken · 2023-08-15 07:00 A quite important note is that the compiler only allows one argument, the source file. I have -va -xd hardcoded right now. This can be changed when I fully grasp the syntax string for arguments. Also true for executables made with the compiler. You can access it with argv[argc-1]. ---------------------------------------------------------------------- micken · 2023-08-15 07:59 Code: [Select]264K switest.aif,ff8 1000K switest,e1f elf version is quite big But it is probably because compiler is built with DEBUG=1. AIF files can be debugged, even though the riscos debugger is quite limited. Below is breakpoint set to inside write, (I THINK!) you can see the address in R0 which is the only argument to OS_Write0, print string in r0. You can see the string in the memory dump. It actually can be useful when hunting memory issues.. hint hint. If interested the offending part is at 0x31c94 in the aif file.. so: in a taskwindow: load ppcarm 8000 breakset 31c94 go 8000 it will stop at break point , you can type "continue" answer Y to question , and it will run to next time breakpoint is met. A quick look in disassembly (aif file) I can find that R0 and R2 are interesting. I think that looking at the address after the call to Os_Alloc is more interesting.. If the returned pointer is bad , that means that my allocator failed... Another useful command is *memory syntax is memory
-- gives you the dump from mmumapped address memory p
-- the same from physical address Code: [Select]*breakset 11a14 *go 8000HelloasmxStopped at break point set at &00011A14 Register dump (stored at &2000D5D0) is: R0  = 0004A684 R1  = 0004A684 R2  = 0000002B R3  = 00000000 R4  = 00000001 R5  = 0004A684 R6  = 0000002B R7  = 0004B00C R8  = 00000000 R9  = 00000000 R10 = 00000067 R11 = 0011BE54 R12 = 0011BE58 R13 = 0011BDF0 R14 = 000341B0 R15 = 00011A14 Mode USR32 flags set: Nzcvqjggggeaift        PSR = 80000010 Debug* *memory 0004A684 Address  :     7 6 5 4     B A 9 8     F E D C     3 2 1 0     7 6 5 4     B A 9 8     F E D C     3 2 1 0 :            ASCII Data 0004A684 :    6C6C6548    7266206F    66206D6F    722F6370    6F637369    53203A73    74204957    21747365 : Hello from fpc/riscos: SWI test! 0004A6A4 :    7465720A    3A6E7275    000A340A    00000000    00000000    00000000    00000000    00000000 : .return:.4...................... 0004A6C4 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ 0004A6E4 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ 0004A704 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ 0004A724 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ 0004A744 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ 0004A764 :    00000000    00000000    00000000    00000000    00000000    00000000    00000000    00000000 : ................................ * ---------------------------------------------------------------------- StefanRISCOS · 2023-08-15 11:26 Quote from: micken on August 14, 2023, 05:54:40 pmYou can see it in Tasks window (PascalWimp) and the source code. Awesome! ---------------------------------------------------------------------- TRon · 2023-08-15 17:17 Quote from: micken on August 15, 2023, 09:59:52 am... AIF files can be debugged, even though the riscos debugger is quite limited. ... Very Interesting as that for sure will help. Thank you for sharing. Any way to invoke the debugger programmatically ? QuoteAnother useful command is *memory Again thank you for sharing. But.. what a convoluted way to display some continuous stream of bytes/data. I am used to big vs little endian but to me and imho this makes no sense whatsoever. You could opt for making a memory dump yourself though (but then some basics such as memory allocation, pointer handling and character outputting needs to work properly). On the other hand, it is at least better than having nothing at all ---------------------------------------------------------------------- micken · 2023-08-15 18:22 Try *help memory It has some options for how it displays memory. I like the command. It is possible to have that kernel module loaded without much other stuff. Extremely useful when porting riscos to new platforms. The debugger module might have swis ,can have a look. https://www.riscosopen.org/wiki/documentation/show/Debugger No useful swis. ---------------------------------------------------------------------- micken · 2023-08-15 20:09 BAH! I tried now setting breakpoints around the call to SysOSAlloc.. rtl/inc/heap.inc Can't really get that working. I can set a breakpoint in SysOSAlloc, right after my allocator returns.. no bad pointers (yet). (re-enabled the first of crash) Code looks like: Code: [Select]  if pmc_next<>nil then    31cb8:       e3520000        cmp     r2, #0         pmc_next^.prev_fixed := pmc;    31cbc:       15820008        strne   r0, [r2, #8] R2 is #0 every time until crash where it is a bad pointer. All calls to SysOSAlloc gives valid ram. R0 points to pmc and is a address from allocator.. Checking for #0 doesn't catch everything. Code: [Select]pmc_next := loc_freelists^.fixedlists[chunkindex];    31ca4:       e7942105        ldr     r2, [r4, r5, lsl #2]       pmc^.next_fixed := pmc_next;    31ca8:       e5802004        str     r2, [r0, #4] More fun! It is freelists that is empty (probably).  pmc_next is set to 0x0 ( as can be seen above) The next store works because pmc is allocated right before. ---------------------------------------------------------------------- micken · 2023-08-16 13:46 Hmm. If I move to next part after the crashing one it looks like this: Code: [Select] loc_freelists^.fixedlists[chunkindex] := pmemchunk_fixed(result);    31cb4:       e7846105        str     r6, [r4, r5, lsl #2] and before Code: [Select]pmc_next := loc_freelists^.fixedlists[chunkindex];    31ca4:       e7942105        ldr     r2, [r4, r5, lsl #2] Very interesting is that the store to loc_freelist (r4) with index (r5) always contains a valid address in r6. But when loading back r2 is 0x0 most of the time. When it crash index is 7 which has been set to valid address previously. This is how it looks like when it stores to index 7 Code: [Select]Register dump (stored at &2000D5D0) is: R0  = 21F34F6C R1  = 00007F90 R2  = 00000000 R3  = 00000071 R4  = 0045B5D4 R5  = 00000007 R6  = 21F2D01C R7  = 00100000 R8  = 21F2D000 R9  = 00000070 R10 = 00000001 R11 = 00927F44 R12 = 00007FDC R13 = 00927E70 R14 = 000369BC R15 = 00031CB4 Mode USR32 flags set: nZCvqjggggeaift        PSR = 60000010 As you can see R6 is a valid address. So.. what on earth happens?? If this didn't work on all existent platforms I would have guessed a variable overflow. If this is the case now on riscos I would call it a bug, but please educate me. ---------------------------------------------------------------------- StefanRISCOS · 2023-08-20 17:45 Quote from: micken on August 15, 2023, 07:34:41 amQuoteSomething like that is available in rtl/linux/arm/syscall.inc named FpSysCall (with overloads for different parameters, and using nostackframe). If possible it would be better to re-use those for consistency. Also note the call to seterrno which sets a systemwide error number. As far as I can see Linux syscalls doesn't return information in a lot of registers.. which is the case for many swi's on riscos. You also need to know that riscos swi is called with swi #number and number is unique for every call. _kernel_swi works like the above ( the last example ). You pass a pointer to register arrays ( probably can be be done with records). and at the end writes back the registers. Also note the self modifying part. Somehow the swi number needs to be passed in. It isn't in a register it is just in the same word as the instruction ( simplified ). So again different than the linux way , where it just calls swi #0 with syscall number in regs. Not sure if the SWI call stuff is solved already between you but I agree with Micken that should have a general RISCOS_SWI() function. That can be called and returns all necessary results. As background info: The RISC OS SWI (Software Interrupt) calls have not only a number but also a text definition but I am not sure how that will be initialized in Pascal. There should be in general a definition or include of this names or simply on top of RISCOS_SWI.pas inside which also the RISCOS_SWI() function is included. The full list is here. List of SWI calls: http://www.riscos.com/support/developers/prm_index/numswilist.html For my taste it is better to use the text than just the number for readablilty of the code. example in BASIC with inline ARM assembler: OS_WriteI = &100 ... [ ... SWI OS_WriteI+ASC">" ...] So in Pascal will be like: $error = RISCOS_SWI("OS_WriteI",">"); Info about register use in RISC OS SWI calls and ARM assembler : http://www.riscos.com/support/developers/prm/asm.html ---------------------------------------------------------------------- StefanRISCOS · 2023-08-22 15:58 Is there any diagram which shows the functional parts of FPC and another from Lazarus? In addition which folders belong to which parts of that diagram. If not would be nice if anyone can do it. For the Lazarus IDE is there a part that is used to implement the graphical user interface and another one for the widget support? Question to Micken: Should we use the toolbox or a lower level implementation? The Lazarus widgets are basically an extented version of the RISC OS toolbox as it includes also more powerful widgets like database access etc. The Lazarus "Toolbox" should use the standard RISC OS files like res (Resource) files (Window, bar and menu definitions) and sprites (for icons and images). Or that will be a problem with compatibility of porting non-RISC OS Lazarus programs to RISC OS? Maybe a converter tool can help here. What are the policies of Lazarus here? ---------------------------------------------------------------------- TRon · 2023-08-23 12:09 Quote from: StefanRISCOS on August 20, 2023, 07:45:18 pmNot sure if the SWI call stuff is solved already between you but I agree with Micken that should have a general RISCOS_SWI() function. That can be called and returns all necessary results. There is nothing that needs to be solved, firstly because not implemented yet but more important you can go either way as well as implement/support both scenarios. I personally disagree for using a common SWI implementation (based upon what I've read so far) because it is unworkable for end-users to know the input and/or output for all the different SWI function calls (even though it is documented). But, for someone being experienced with assembler calls like that it should not be a problem and you probably expect for all CPU registers to return their value just as you would probably like to have full control over setting the content of those registers as well. Concerning your basic language usage example, yes something like that is no problem to implement in Pascal though I favour using routines with their respective names as that allows for a more polished end- user experience. But the different SWI names can be static constants as well, that is no problem. ---------------------------------------------------------------------- TRon · 2023-08-23 12:38 Quote from: StefanRISCOS on August 22, 2023, 05:58:33 pmIs there any diagram which shows the functional parts of FPC and another from Lazarus? No, not really. Free Pascal units are about the language and basic functionality that is used from the command-line, so file handling, serial/parallel interface, memory management, database access, SDL/GL, networking, TUI interface  etc. though there are units available that help in manually writing GUI interfaces for example cocoa, gtk, Windows etc (in case you like to punish yourself). Lazarus is more about the GUI itself (components, interfaces), though there are also some generic units that imho belong to Free Pascal because they are basically non visual components or offer no components at all (just classes/objects/additions). QuoteIn addition which folders belong to which parts of that daigram. Oh, you can see that for yourself pretty quick by installing Free Pascal and Lazarus separately. FPC uses it's own units, while all things belonging to Lazarus is situated in the Lazarus directories. I do no believe there is such a diagram. There is one for all components and their inheritance though (it is part of the Lazarus IDE). QuoteFor the Lazarus IDE is there a part that is used to implement the graphical user interface and another one for the widget support? Bit of a trick question as the IDE itself is something else than Lazarus (it is rather part of). There is a clear separation between: - GUI, the components used to write/design applications, which is widgetset independent (at least should be). - The widgetset, which is a front-end for the GUI offered by the OS so its actual implementation has all the gory details) - The  IDE which is an application written/designed in/with Lazarus that uses GUI components but also allows you to use those components at designtime to resize and assign their events, properties etc which is done by interacting with your source-code using the object inspector (amongst others). So what you usually do is find a existing widgetset that you are familiar with, say for example windows, look at the widgetset implementation (understand the calls made to windows functionality) and re-implement the behaviour of a widget using your OS offered GUI. Lazarus itself (actually it is Free Pascal) has proficiency for storing resources in an application. If your OS offers the graphical bits itself (windows does for example with icons' etc) then you do not have to include those in your application but just use the corresponding windows settings to for example draw a messagebox with an exclamation mark). As a hint, one of the first things you would have to do when implementing support for a new widgetset is implementing the canvas (which is a drawing surface). All other functionality of a component (graphical wise) is based on that. QuoteThe Lazarus widgets are basically an extented version of the RISC OS toolbox as it includes also more powerful widgets like database access etc. The Lazarus "Toolbox" should use the standard RISC OS files like res (Resource) files (Window, bar and menu definitions) and sprites (for icons and images). As mentioned above. Lazarus is not designed to implement OS specific features in its offered components, rather you need to make sure that existing components behave the same on your OS/GUI. Having said that, i had also already stated that whenever that is not an option, that it is possible to make your own widget implementation tailured for only your OS but in that case you won't be able to use the IDE to design your applications since it will not be using the offered components in that case (I have not seen a platform yes that went out of its way and offer platform specific visual components, but someone please correct if I'm wrong about that). There is also an alternative solution, named fpGUI toolkit (not to be confused with the fpGUI interface for Lazarus) which does not adapt their widgets to/from the OS but implement widgets in a way that they all look/behave exactly similar, no matter what target you choose, so they are fully custom drawn (Lazarus also has some custom drawn components that so not obey OS rules/standards). QuoteMaybe a converter tool can help here. What are the policies of Lazarus here? Hopefully that gives you some insight but understand that it is only a /little/ insight. It will simply take too much time to explain everything and in practice it is much faster to have a look at the code (but it will take some time to get yourself familiar with it especially when it comes to the "gory" details). For more information: - Development status for the individual widgetsets - Adding a new interface (that page also contains other links of importance such as "Lazarus known issues (things that will never be fixed) - A list of interface compatibility issues" ---------------------------------------------------------------------- micken · 2023-08-24 14:03 I think it is best to stay with the fpc port until done before speculating in widgets. I am not going to do much more, but I am happy to assist with riscos specific issues. ---------------------------------------------------------------------- TRon · 2023-08-26 16:13 Quote from: micken on August 24, 2023, 04:03:00 pmI think it is best to stay with the fpc port until done before speculating in widgets. I agree to that. It is not very advisable to try and breathe while not being born yet  QuoteI am not going to do much more, but I am happy to assist with riscos specific issues. Thank you for your support. ---------------------------------------------------------------------- StefanRISCOS · 2023-08-28 12:54 @TRon Thanks for good explanations about Lazarus/FPC. QuoteAs mentioned above. Lazarus is not designed to implement OS specific features in its offered components, rather you need to make sure that existing components behave the same on your OS/GUI. When talking about the RISC OS toolbox the intention was not to implement RISC OS features into Lazarus but to find solutions to implement the Widgets for Lazarus.  RISC OS has graphic elements like labled box, input field, text field, dropdown, sprites, text area, option and radio buttons, buttons, slider, adjuster arrows. There is no native tabs support. But there is a settings tool called ConfiX that uses heavily tabs. ---------------------------------------------------------------------- kveroneau · 2023-11-02 20:06 Just learning now that there is some progress in this port, that's awesome!  I've been getting into RISC-OS more as the primary OS of an original Raspberry Pi 1 model B, as it runs much better than modern Linux, but I really don't care for it's better supported BASIC language included, I'd personally love to create programs for it in FPC and Lazarus.  So count me in as super hyped for such an upcoming port.  PS, RISC-OS is pretty darn amazing and everyone should give it a shot at least once.  It's so unique as an OS in so many ways. ---------------------------------------------------------------------- StefanRISCOS · 2023-12-31 10:05 I just got an important informtation from Micken(Michael). In order to be able to run FPC on the RISC OS emulators like RPCemu or VirtualRPC we need to patch the compiler to replace  ARM assembler code “BX LR “ to “MOV PC,LR". This is because the emulators only supports ARMv6 not ARMv7. I am planing to release a polished ZIP with Micken's Alpha version of FPC in the next days. The alpha version of FPC only accepts one parameter (the filename to compile) so compiler directives must be switched on/off by inline code. ---------------------------------------------------------------------- TRon · 2023-12-31 10:27 Quote from: StefanRISCOS on December 31, 2023, 11:05:39 amThis is because the emulators only supports ARMv6 not ARMv7. Hi Stephan, I can not apologize enough for the delay from my hand  A brief reaction: Code: Pascal  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i fpc -Parm -ic tells us: Code: [Select]ARMV3 ARMV4 ARMV4T ARMV5 ARMV5T ARMV5TE ARMV5TEJ ARMV6 ARMV6K ARMV6T2 ARMV6Z ARMV6M ARMV7 ARMV7A ARMV7R ARMV7M ARMV7EM Thus the question becomes, which exact (minimal) CPU (instructionset) do(es) the emulator(s) support ? You can specify the arm specific CPU (sub)target when (cross)compiling the compiler and the mentioned issue should be resolved. see also https://wiki.freepascal.org/ARM_compiler_options ---------------------------------------------------------------------- StefanRISCOS · 2024-01-02 13:36 @Tron  Good to see that you are alive. Thanks for that info! I also didn't have much time to continue on this project but I hope I can spend more time on it this year. Happy New Year! ---------------------------------------------------------------------- PascalDragon · 2024-01-02 22:34 Quote from: StefanRISCOS on December 31, 2023, 11:05:39 amThis is because the emulators only supports ARMv6 not ARMv7. Then change the target processor type to one that does not support BX, namely ARMV4 (e.g. -Cparmv4). Please note that you probably mean ARM6 which is different from ARMv6, because the later does support BX (see also here). ---------------------------------------------------------------------- micken · 2024-02-15 23:20 Quote from: PascalDragon on January 02, 2024, 11:34:32 pmQuote from: StefanRISCOS on December 31, 2023, 11:05:39 amThis is because the emulators only supports ARMv6 not ARMv7. Then change the target processor type to one that does not support BX, namely ARMV4 (e.g. -Cparmv4). Please note that you probably mean ARM6 which is different from ARMv6, because the later does support BX (see also here). I know it is a option. My port is a quick and dirty test and it was quick for me to binary patch the fpc executable. The binaries that fpc produces doesn't have bx lr.