hello-pfs154 const string "Hello World!" is placed in code memory byte by byte

[freepdk]

I tried to compile the hello pfs154 and saw that the const string "Hello World!" is placed in code memory const section byte by byte (2 byte per instruction word).

The PFS154 only can store 14 bit per instruction word which means that 2 bits of every second byte will be missing.

I think a byte array like "const char*" should use 1 instruction word per byte (wasting the upper bits).

BTW: Since this is a sdcc related thingy what would be best place to report this kind of problems?

[spth]

Yes, it shall be implemented as one ret k per byte with k for the byte value.
It just didn't get implemented yet (originally my preferred solution was to do this in the assembler, but now I'm also considering doing it in the compiler instead).

Best place is probably an SDCC tracker or mailing list.

Philipp

[spth]

The transition to ret k should be complete in current SDCC (revision 10908).

Philipp

[freepdk]

Hi,

great work. Saw the ret k produced now. So much better than mini-C already :-)

unfortunately a clean build does not produce a pdk14.lib (SVN branch revision 10908):

time.asm:1829: Error: machine specific addressing or addressing mode error
...

Also a disassembly of the final hex/bin file revealed that some CALL and GOTO targets are calculated incorrect (e.g. totally wrong destinations for last jump in main endless loop and call to external lib function "_puts")

JS

EDIT: pdk tools can now disassemble BIN files by supplying the OTP_ID:
dispdk 2AA1 test.bin

[freepdk]

Ok,
checked out your latest commit (rev 10912) and pdk14.lib was created fine.

looks I'm wrong. Only last jump in main seems to end up nowhere. No specific correlation to a label.

I investigated the wrong jump targets and it looks like it is caused by having the same ?local? label multiple times:

e.g. in .asm intermediate output you get something like

; function send_bit
_send_bit:
push af
...
mov a, _sending+0
ceqsn a, #0x00
goto 00104$
...
00104$:
...

; function main
_main:
...
00104$:
...
goto 00104$
...

==> The goto in main jumps to the label in first function defining it (_send_bit).

---

Also all "return" statements from inside interrupt should generate a "ret i".
Right now a normal ret is inserted:
;>test.c: 34: if(!sending)
mov a, _sending+0
ceqsn a, #0x00
goto 00104$
;>test.c: 35: return;
ret
00104$:
...

[spth]

The return interrupts is fixed now. Regarding the labels, I wonder why it works for other architectures, but not pdk14.

Philipp

[freepdk]

Hi,

the assembly looks fine. Maybe assembler or linker is causing the problem.

Meanwhile I debugged the HelloPFS154 (I ported it back to mini-c) and found some issues

1. in interrupt you have to reset the interrupt request for TM2. Something like this:
   if( intrq & 0x40 )
   {
   intrq &= ~0x40;
   ...

2. in putchar you must reset the TM2 counter since TM2 always is counting (otherwise startbit has wrong length):

__sfr __at(0x1d) tm2ct;

after sending = true; insert this
tm2ct = 0; //reset timer counter for first bit

3.) clkmd = 0x30; crashes since it disables IHRC
clkmd = 0x34; is all you need, it already disables watchdog

4.) timer prescalers and calculation are wrong
tm2s = 0x60; is SYSCLK, /64, /1 ==> timer = SYSCLK/( 2 * PRESCALER * (SCALER+1) => 62.5 kHz
tm2b = 60; // Divide by 52 ~> 1201 Hz //60 by oscilloscope on PFS154

(Not sure why is so big difference 52 <==> 60 , maybe because I was not tuning the IC)

5.) just a note:
for(unsigned long int i = 0; i < 150000; i++); // Wait approx. 3s.
requires 10 more instructions than
for(unsigned long int i=150000; i>0; i--); // Wait approx. 3s.

I pushed the ported and corrected version to the "simple-pdk-code-examples"

[Rakete1111]

@freepdk can you check again please?

Compiling your updated hello.c gives me for the last goto in main:

0000E6                        276 00104$:
...
00010A 73 30                  295   goto  00104$

0x73 * 2 == 0xE6 so it seems to be working for me.

[spth]

I made some fixes in the example code a few days ago. 1) and 2) are fixed as suggested. For 3) I had used the example from the datasheet, but looking at the details again, I now changed it (though I did it in two steps again, since the datasheet says, that the ILRC may not be disabled at the moment of the switch to the IHRC). I'll redo the calculations for 4) later and fix it then.

[freepdk]

sdcctestjump.zip

Hi,

I investigated a bit more (version 10921) and found out how to reproduce:

When using the HElloPFS example the jump is translated fine (as @Rakete1111 reported).

However when you insert more than 1 function call in the endless loop I get the problem.

In order to produce something usable I was replacing the printf("...") with a sequence of putchars(...):

main:

...

  for(;;)
  {
//    printf("Hello World!\n"); //does not work yet

    putchar('H');
    putchar('e');
    putchar('l');
    putchar('l');
    putchar('o');
    putchar(' ');
    putchar('W');
    putchar('o');
    putchar('r');
    putchar('l');
    putchar('d');
    putchar('!');
    putchar('\n');

    for(unsigned long int i = 0; i < 150000; i++); // Wait approx. 3s.
  }
}

When using only one putchar('X') call in the loop the jump is fine. As soon as I insert 2 or more putchar calls the JUMP of the loop is pointing to nowhere.

UPDATE:

It also happens if I insert more stuff to _sdcc_external_startup() function (for quick test I used "__asm" ... "__endasm;" and added 10 NOPs inside. So maybe an overflow in assembler when calculating jump targets?

=> I added the code as attachment (shown on top)

[Rakete1111]

Well that's embarrassing, my bit arithmetic was wrong when the address uses more than 8 bits :(. Thanks, here's a patch to fix this @spth

Index: sdas/linksrc/lkrloc3.c
===================================================================
--- sdas/linksrc/lkrloc3.c      (revision 10918)
+++ sdas/linksrc/lkrloc3.c      (working copy)
@@ -448,7 +448,7 @@
 
                         /* pdk addresses in words, not in bytes. */
                         rtval[rtp] /= 2;
-                        rtval[rtp] |= rtval[rtp + 1] & 1;
+                        rtval[rtp] |= (rtval[rtp + 1] & 1) << 7;
                         rtval[rtp + 1] /= 2;
 
                         /* Do the actual opcode fusion and ignore the extra

[freepdk]

GREAT 🥇

This fixed the goto problem.

I can't express how happy I am :-)

So maybe today is the day when I can stop using the PADAUK IDE :-)

[freepdk]

Hi,

almost there. I found 2 more issues using revision 10926 (manually disassembled and commented the final output binary ):

1. assembler/linker does not insert position of "ret x" string

main:

...
;mov	a, #<(___str_1 + 0)
0x006c:   0x2f00    MOV A, 0x00    ;0 <================????
0x006d:   0x0b80    MOV [0x00], A
;mov	a, #((___str_1 + 0) >> 8)
0x006e:   0x2f00    MOV A, 0x00    ;0 <================????
0x006f:   0x0b81    MOV [0x01], A
;call	_puts
0x0070:   0x3884    CALL 0x084     ;CALL _puts
...
                                    295 	.area CODE
                                    296 	.area CONST
      00015C                        297 ___str_1:
      00015C 48 02                  298 	ret #0x48	; H
      00015E 65 02                  299 	ret #0x65	; e
      000160 6C 02                  300 	ret #0x6c	; l
      000162 6C 02                  301 	ret #0x6c	; l
      000164 6F 02                  302 	ret #0x6f	; o
      000166 20 02                  303 	ret #0x20	;  
      000168 57 02                  304 	ret #0x57	; W
      00016A 6F 02                  305 	ret #0x6f	; o
      00016C 72 02                  306 	ret #0x72	; r
      00016E 6C 02                  307 	ret #0x6c	; l
      000170 64 02                  308 	ret #0x64	; d
      000172 21 02                  309 	ret #0x21	; !
      000174 00 02                  310 	ret #0x00
                                    311 	.area CABS (ABS)

2. __gptrget seems wrong (using IDXM to access memory but should use PCADD to jump to "ret x" position)

=> EDIT... found the source of __gptrget and it looks fine. Your idea was even better to manipulate the return pointer on stack for the long jump :-)

[freepdk]

Update,

Form .lst file:

...
      0000DE CA 30                  301  goto 00108$
      0000E0                        302 00112$:
                                    303 ; test.c: 107: }
      0000E0 7A 00                  304  ret
                                    305  .area CODE
                                    306  .area CONST
      000000                        307 ___str_1:
      000000 48 02                  308  ret #0x48>; H
      000002 65 02                  309  ret #0x65>; e
...

As you can see the .area CODE . area CONST is starting a new segment and therefore the address resets to 0.

After removing the new segment starts the string was placed directly after code and the MOV A,#(___str1+0) produced some value.

Unfortunately the value is still wrong and same value is inserted for lo and hi byte.

When looking at other processor (e.g. STM8) .lst file of assert.asm (also contains a string) you can see that some ?relocation symbols are visible (r / s before the inserted address):

assert.lst from stm8:

...
00000C 4Br00            [ 1]    64 push #<(___str_0 + 0)
00000E 4Bs00            [ 1]    65 push #((___str_0 + 0) >> 8)
...
                                72 .area CODE
                                73 .area CONST
000000                          74 ___str_0:
000000 41 73 73 65 72 74 28     75 .ascii "Assert(%s) failed in function %s at line %u in file %s."

However the .lst file from pdk14 does not contain any of those markers:

      0001E8 00 2F                  277  mov a, #<(___str_1 + 0)
                                    278 ; mov _puts_PARM_1+0, a
      0001EA 00 2F                  279  mov a, #((___str_1 + 0) >> 8)
                                    280 ; mov _puts_PARM_1+1, a
...
                                    305 .area CODE
                                    306 .area CONST
      000282                        307 ___str_1:
      000282 48 02                  308 ret #0x48>; H
      000284 65 02                  309 ret #0x65>; e
      000286 6C 02                  310 ret #0x6c>; l