ROOL Forum: Recent Posts

Next MUG meeting via Zoom, 7:30pm Wednesday 24th July 2024

Mon, 22 Jul 2024 06:45:21 -0000

The next meeting of the RISC OS Midland User Group (MUG) will take place, via Zoom, at 7:30pm Wednesday 24th July 2024.

This is a special out of plan meeting, via Zoom, where John Rickman will be covering using StrongEd as a scripting aid for Python and other programming techniques.

If you have previously been on a MUG Zoom call then the access details remain the same as before or you can obtain the details via contacting MUG.

We look forward to welcoming new and existing members to our meetings.

The MUG Events team.

Debugger module commands

Sun, 21 Jul 2024 16:03:32 -0000

These have been partially implemented – the *BreakSet, *BreakClr and *BreakList commands are implemented and the breakpoints are written, but the *Debug and *Continue are not, and the exception buffer isn’t updated properly.

Next week’s Live Coding will have to finish that off.

Live Coding with Gerph, Sunday 21st July

Sun, 21 Jul 2024 16:01:57 -0000

Live coding is done now and there was pretty reasonable progress, although I didn’t quite get it all done.

And I also had to update RISC OS Pyromaniac to add an ABT stack, as there hadn’t been one defined. I’ve allocated DA 51 for this.

So what we have left to do is…

The prefetch handler was a bit of a stretch for me, these days. I definitely don’t remember that stuff as well as I used to.

You can find the progress so far on the ‘breakpoints-implementation’ branch at https://github.com/gerph/darm/tree/breakpoints-implementation

Is this a quirky compiler bug?

Sun, 21 Jul 2024 15:05:22 -0000

A quick check here shows it compiles down to 3 instructions just the same as resorting to inline assembler.

It does now, now that the compiler has been extended to understand swix.
Previously, it was extremely hairy. ;)

(unless you explicitly mark them volatile)

That’s the solution I settled on.

Is this a quirky compiler bug?

Sun, 21 Jul 2024 14:26:39 -0000

PS: No comments about using inline assembler please.

Except the irony here is if you’d just written

_swix(Wimp_Extend, _INR(0,1), 11, sizes);

it would have avoided the problem that for inline assembler the compiler has no clue why you’re passing sizes in R1 nor what side effects the SWI might have so is at liberty to have kept values in its head (unless you explicitly mark them volatile). A quick check here shows it compiles down to 3 instructions just the same as resorting to inline assembler.

Is this a quirky compiler bug?

Sun, 21 Jul 2024 13:13:07 -0000

Druck – the sort of messy stuff you’d expect from a compiler. I had to go back quite a way to spot where the MVN for -1 was… quite a way back actually.

0000F314 : .‘àã : E3E09000 : MVN     R9,#0
0000F318 : .‘¨å : E5A89008 : STR     R9,[R8,#8]!
0000F31C : ®..ë : EB0007AE : BL      &000111DC          ; call: grid_createcaret
0000F320 : .0 ã : E3A03000 : MOV     R3,#0
0000F324 : .0-å : E52D3004 : STR     R3,[R13,#-4]!      ; all of this guff is for sorting
0000F328 : 0’”í : ED959130 : LDFD    F1,[R5,#192]       ; out the size to send to SetExtent
0000F32C : Ŵ¡flí : ED9FA181 : LDFD    F2,&0000F538
0000F330 : .. ã : E3A01000 : MOV     R1,#0
0000F334 : ŵ1.î : EE113182 : MUFD    F3,F1,F2
0000F338 : s..î : EE100173 : FIXZ    R0,F3
0000F33C : .0ۉ : E2803002 : ADD     R3,R0,#2
0000F340 : ŷ.ŷà : E0860186 : ADD     R0,R6,R6,LSL #3
0000F344 : ..ۈ : E0800206 : ADD     R0,R0,R6,LSL #4
0000F348 : .. á : E1A00100 : MOV     R0,R0,LSL #2
0000F34C : (.ۉ : E2800028 : ADD     R0,R0,#&28         ; ="("
0000F350 : . `â : E2602000 : RSB     R2,R0,#0
0000F354 :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F358 : `..ë : EB001660 : BL      &00014CE0          ; call: Window_SetExtent
0000F35C :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F360 : .Йâ : E28DD004 : ADD     R13,R13,#4
0000F364 : .. á : E1A0100D : MOV     R1,R13
0000F368 : ...ë : EB001C7F : BL      &0001656C          ; Somewhere around here we should also
0000F36C : Ø..ë : EB001CD8 : BL      &000166D4          ; be calling GetWindowState, turning the
0000F370 :  ӌ : E59520AC : LDR     R2,[R5,#172]       ; Hourglass off, and setting a value TRUE.
0000F374 : .0 ã : E3A03001 : MOV     R3,#1              ; <--- which is probably this ;)
0000F378 : ¤0Ŷå : E58530A4 : STR     R3,[R5,#164]
0000F37C : ..Rã : E3520000 : CMP     R2,#0              ; Now we start the "if (something)" block
0000F380 : Ò... : 0A0000D2 : BEQ     &0000F6D0          ; skip over it if false
0000F384 : ´aflå : E59F61B4 : LDR     R6,&0000F540       ; otherwise here goes the above code
0000F388 : ..„å : E5961000 : LDR     R1,[R6,#0]
0000F38C :  0ӌ : E5953020 : LDR     R3,[R5,#32]
0000F390 : \‘-å : E52D905C : STR     R9,[R13,#-92]!
0000F394 : .0-å : E52D300C : STR     R3,[R13,#-12]!
0000F398 : €@Aâ : E2414080 : SUB     R4,R1,#&80         ; ="€"
0000F39C : .‘™å : E58D9010 : STR     R9,[R13,#16]
0000F3A0 : .. ã : E3A0000B : MOV     R0,#&0B            ; =11
0000F3A4 : .. á : E1A0100D : MOV     R1,R13
0000F3A8 : û..ï : EF0600FB : SWI     XWimp_Extend
0000F3AC : .0‡å : E59D3014 : LDR     R3,[R13,#20]
0000F3B0 : .  á : E1A02009 : MOV     R2,R9
0000F3B4 : .. á : E1A01009 : MOV     R1,R9
0000F3B8 : ..-é : E92D000E : STMDB   R13!,{R1-R3}
0000F3BC : .0™â : E28D300C : ADD     R3,R13,#&0C        ; =12
0000F3C0 : ..ݏ : E893000E : LDMIA   R3,{R1-R3}
0000F3C4 : ^.•â : E28F0F5E : ADR     R0,&0000F544       ; -> string: "%d, %d, %d, %d, %d, %d."
0000F3C8 : ­ãÿë : EBFFE3AD : BL      &00008284          ; call: debug
0000F3CC : .Йâ : E28DD00C : ADD     R13,R13,#&0C       ; =12
0000F3D0 : .€‡å : E59D800C : LDR     R8,[R13,#12]
0000F3D4 : .p‡å : E59D7010 : LDR     R7,[R13,#16]
0000F3D8 : ..xã : E3780001 : CMN     R8,#1
0000F3DC : (€ . : 03A08028 : MOVEQ   R8,#&28            ; ="("
0000F3E0 :  .ӌ : E5950020 : LDR     R0,[R5,#32]
0000F3E4 : ..wã : E3770001 : CMN     R7,#1
0000F3E8 : (p . : 03A07028 : MOVEQ   R7,#&28            ; ="("

If I omit the debug() call, then the compiler over-optimises to this…

0000F3A4 : û..ï : EF0600FB : SWI     XWimp_Extend
0000F3A8 : (‘ ã : E3A09028 : MOV     R9,#&28            ; ="("
0000F3AC : (p ã : E3A07028 : MOV     R7,#&28            ; ="("

;)

That’s what makes me wonder if there’s some sort of quirky bug at play here. I could understand if it decided that the value was -1 and just optimised to that which, as Stuart says, is the compiler not spotting that the values have changed… but differing behaviour on whether or not the value is printed out before it is used? Why…?

Is this a quirky compiler bug?

Sun, 21 Jul 2024 12:50:01 -0000

Get the compiler to spit out assembler listing to see the actual code which has been generated.

Is this a quirky compiler bug?

Sun, 21 Jul 2024 12:47:53 -0000

Not a bug. Compiler hasn’t been given a hint that the sizes array content has been modified, so sizes[3],[4] are legit the same values post-asm block as initialised with.

Myself I tend to put trivial asm blocks like this in inline functions; problem never arises.

Is this a quirky compiler bug?

Sun, 21 Jul 2024 12:37:50 -0000

I’m using compiler v5.89 v5.92.

The following code is in use:

   if ( some_condition_or_other )
   {
      int  sizes[26];

      sizes[0] = main_window;
      sizes[3] = -1;
      sizes[4] = -1;
      __asm
      {
         MOV   R0, 11 // Read window size information
         MOV   R1, sizes
         SWI   (SWI_Wimp_Extend + XOS_Bit), {R0,R1}, {}, {PSR}
      } 
      debug("sizes: %d, %d, %d, %d, %d, %d...\n",
            sizes[0], sizes[1], sizes[2], sizes[3], sizes[4], sizes[5]);
      rborder = sizes[3];
      tborder = sizes[4];
      if ( rborder == -1 )
         rborder = 40; // actual value for this window read from my Pi
      if ( tborder == -1 )
         tborder = 40; // ditto

      // ...etc...
   }

What I’m doing is trying to get the sizes of certain parts of the window, specifically the size of the title bar and right scroll bar, in order to provide correction for window opening positions. I’m using -1 to detect cases where this call isn’t supported to push in a default value.

Problem is, this code returns:

sizes: 542164089, 0, 327, -1, -1, 454...

Now, the weird thing is that if I copy the debug call to do it twice in a row, then this happens:

sizes: 542170073, 2, 40, -1, -1, 38...
sizes: 542170073, 2, 40, 40, 40, 38...

Solutions? Several options.

Is this normal behaviour?
It seems as if old values from directly setting the values are stored in registers prior to the SWI call which need to be flushed somehow; as using the array in the SWI call doesn’t trigger this (perhaps the compiler treats “sizes” and “sizes[3]” as two different things and there’s no method of telling the compiler that the array itself has changed?

Hmm, just found the DDE archive on my phone, this machine is a few versions out of date.
Let me update the compiler and try again.
Latest version, same behaviour.

PS: No comments about using inline assembler please. My DeskLib doesn’t have this call and I’ve not gotten around to adding it. Using inline assembler is, for me, the simplest way to do a SWI call when there’s no corresponding library function to use.

Develo?

Sat, 20 Jul 2024 22:01:03 -0000

Quite so. Oops!

Develo?

Sat, 20 Jul 2024 19:45:53 -0000

Devolo.