Lazarus for RISC OS

[micken]

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]

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 <address in hex (not 0x)> -- gives you the dump from mmumapped address
memory p <address in hex (not 0x)> -- 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]

You can see it in Tasks window (PascalWimp) and the source code.

Awesome! 

[TRon]

...
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 ?

Another 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]

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]

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]

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]

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.

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]

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]

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.

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]

Is 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).

In 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).

For 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.

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).

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).

Maybe 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]

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]

I 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 

I am not going to do much more, but I am happy to assist with riscos specific issues.

Thank you for your support.

[StefanRISCOS]

@TRon
Thanks for good explanations about Lazarus/FPC.
 

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.

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]

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.