Was there an older version of sdcc that supported the MCS-48 8035 ? I know it's not well suited for C, but for a simple program, and they used to say the same about the 8051 :)
Hi Looks good. Thx for your help Chris Le lun. 23 févr. 2026 à 22:47, Janko Stamenović janko-5@users.sourceforge.net a écrit : I haven't used 8051 or sdas8051 but I know how what asxxxx assembler accepts, so I'm quite sure at least this should give you the same addresses for the first two variables named SWITCH and VARX: FIRST .EQU 0x20 SWITCH .EQU 0x20 SWT0 .EQU 8(SWITCH-FIRST)+0 SWT1 .EQU 8(SWITCH-FIRST)+1 SWT2 .EQU 8(SWITCH-FIRST)+2 SWT3 .EQU 8(SWITCH-FIRST)+3 SWT4 .EQU 8(SWITCH-FIRST)+4 SWT5...
I haven't used 8051 or sdas8051 but I know how what asxxxx assembler accepts, so I'm quite sure at least this should give you the same addresses for the first two variables named SWITCH and VARX: FIRST .EQU 0x20 SWITCH .EQU 0x20 SWT0 .EQU 8*(SWITCH-FIRST)+0 SWT1 .EQU 8*(SWITCH-FIRST)+1 SWT2 .EQU 8*(SWITCH-FIRST)+2 SWT3 .EQU 8*(SWITCH-FIRST)+3 SWT4 .EQU 8*(SWITCH-FIRST)+4 SWT5 .EQU 8*(SWITCH-FIRST)+5 SWT6 .EQU 8*(SWITCH-FIRST)+6 SWT7 .EQU 8*(SWITCH-FIRST)+7 VARX .EQU 0x21 VARX0 .EQU 8*(VARX-FIRST)+0...
I haven't used 8051 or sdas8051 but I know how what asxxxx assembler accepts, so I'm quite sure at least this should give you the same addresses for the first two variables named SWITCH and VARX: FIRST .EQU 0x20 SWITCH .EQU 0x20 SWT0 .EQU 8*(SWITCH-FIRST)+0 SWT1 .EQU 8*(SWITCH-FIRST)+1 SWT2 .EQU 8*(SWITCH-FIRST)+2 SWT3 .EQU 8*(SWITCH-FIRST)+3 SWT4 .EQU 8*(SWITCH-FIRST)+4 SWT5 .EQU 8*(SWITCH-FIRST)+5 SWT6 .EQU 8*(SWITCH-FIRST)+6 SWT7 .EQU 8*(SWITCH-FIRST)+7 VARX .EQU 0x21 VARX0 .EQU 8*(VARX-FIRST)+0...
I haven't used 8051 or sdas8051 but I know how what asxxxx assembler accepts, so I'm quite sure at least this should give you the same addresses for the first two variables named SWITCH and VARX: FIRST .EQU 0x20 SWITCH .EQU 0x20 SWT0 .EQU 8*(SWITCH-FIRST)+0 SWT1 .EQU 8*(SWITCH-FIRST)+1 SWT2 .EQU 8*(SWITCH-FIRST)+2 SWT3 .EQU 8*(SWITCH-FIRST)+3 SWT4 .EQU 8*(SWITCH-FIRST)+4 SWT5 .EQU 8*(SWITCH-FIRST)+5 SWT6 .EQU 8*(SWITCH-FIRST)+6 SWT7 .EQU 8*(SWITCH-FIRST)+7 VARX .EQU 0x21 VARX0 .EQU 8*(VARX-FIRST)+0...
Hi. I am trying to port some code from a project on IAR onto sdas8051. code: RSEG BITVARS SWITCH EQU 020H SWT0 EQU SWITCH.0 SWT1 EQU SWITCH.1 SWT2 EQU SWITCH.2 SWT3 EQU SWITCH.3 SWT4 EQU SWITCH.4 SWT5 EQU SWITCH.5 SWT6 EQU SWITCH.6 SWT7 EQU SWITCH.7 many vars are declared like SWITCH with some aliases for bitfileds. I did not find how to port this on sdas8051. Thanks
[ucsim-r6k] Start implement r6k specific insts: ld cc,mn
Recommendation to add '--disable-pipes' to configure.ac
Special case SOF in genMinusDec().
Special case SOF in genrsh16().
Add special case for SOF in genAssignLit().
Reduce diff to upstream GNU binutils 3.38.
Reduce diff to upstream GNU binutils 3.38.
Fix bug #3937 test for pre-C23 host compilers.
Enable test for bug #3937.
uCsim r4k neg hl carry flag
[ucsim] Check network lib of haiku
Gameboy uCsim h flag on dec r
[r16254]
[ucsim-z80] Fix #3938 Gameboy uCsim h flag on dec r
Merge GNU binutils 2.44 into SDCC fork
As of [16253], libiberty has been synced with upstream binutils 2.46. I hope to be able to do the rest of the upgrade within a week or so.
Sync libiberty with GNU binutils 2.46.
Reduce diff to upstream GNU binutils 3.38.
I noticed that a further mcs51 peephole rule reduces the size again by 2 bytes and also increase the speed.
Reduce diff to upstream GNU binutils 3.38.
Reduce diff to upstream GNU binutils 3.38.
Include mos6502-stack-auto library in Windows installer.
sm83 parameter value passing issues
The bug itself should be fixed in [r16248], but the test can only be enabled after [bugs:#3938] is fixed, too.
Fix bug #3973.
Gameboy uCsim h flag on dec r
The test is in [r16247]., disabled for sm83 for now. The bug was first discovered by an SDCC user that notified me by email.
Test for bug #3937.
sm83 parameter value passing issues
Defect can be closed. Does not occur in 4.6.0 anymore. Attached patch further reduces the size to 24 bytes by removing an IMO superfluous reload of A. Regards, Ruud
This is an output of upstream asrab 5.50 from 2023 1 .r2k 0000 3E 33 [ 4] 2 ld a, 0x33 0002 3E 33 [ 4] 3 ld a, 0x3333 0004 3Er0B [ 4] 4 ld a, var 0006 3Er0B [ 4] 5 ld a, #var 0008 3Ar0Bs00 [ 9] 6 ld a,(var) 000B 21 00 7 var: .dw 33 and this of upstream asz80 5.50 from 2023: 0000 3E 33 [ 7] 1 ld a, 0x33 0002 3E 33 [ 7] 2 ld a, 0x3333 0004 3Er0B [ 7] 3 ld a, var 0006 3Er0B [ 7] 4 ld a, #var 0008 3Ar0Bs00 [13] 5 ld a,(var) 000B 21 00 6 var: .dw 33 The start with ( always had a special meaning, it was...
This is an output of upstream asrab 5.50 from 2023 1 .r2k 0000 3E 33 [ 4] 2 ld a, 0x33 0002 3E 33 [ 4] 3 ld a, 0x3333 0004 3Er0B [ 4] 4 ld a, var 0006 3Er0B [ 4] 5 ld a, #var 0008 3Ar0Bs00 [ 9] 6 ld a,(var) 000B 21 00 7 var: .dw 33 and this of upstream asz80 5.50 from 2023: 0000 3E 33 [ 7] 1 ld a, 0x33 0002 3E 33 [ 7] 2 ld a, 0x3333 0004 3Er0B [ 7] 3 ld a, var 0006 3Er0B [ 7] 4 ld a, #var 0008 3Ar0Bs00 [13] 5 ld a,(var) 000B 21 00 6 var: .dw 33 The start with ( always had a special meaning, it was...
This is an output of upstream asrab 5.50 from 2023 1 .r2k 0000 3E 33 [ 4] 2 ld a, 0x33 0002 3E 33 [ 4] 3 ld a, 0x3333 0004 3Er0B [ 4] 4 ld a, var 0006 3Er0B [ 4] 5 ld a, #var 0008 3Ar0Bs00 [ 9] 6 ld a,(var) 000B 21 00 7 var: .dw 33 and this of upstream asz80 5.50 from 2023: 0000 3E 33 [ 7] 1 ld a, 0x33 0002 3E 33 [ 7] 2 ld a, 0x3333 0004 3Er0B [ 7] 3 ld a, var 0006 3Er0B [ 7] 4 ld a, #var 0008 3Ar0Bs00 [13] 5 ld a,(var) 000B 21 00 6 var: .dw 33 The start with ( always had a special meaning, it was...
Could there be a risk of the last argument in ld a,0x33 cp 4 being meant as an address by the programmer? Especially for ld a,0x33, it might not be obvious if this should be 0xfe 0x04 vs. 0x3a 0x04 0x00.
Starting from [r16246] the all following are possible with sdasrab: 000000 3E 33 2 ld a,0x33 000002 FE 04 3 cp 4 000004 DD 7E FF 4 ld a,-1(ix) 000007 DD A8 5 sll 1, bcde which matches a little more what the Z80 programmers expect. It's already possible upstream in asxxxx (Edit: the principle for the implemented instructions, definitely not the >r2k instructions!) Note: I still haven't modified sdasz80 (which others would also need the modification to allow the same for all "Z80-like" generated code?...
Improved register tracking for mcs51
Starting from [r16246] the all following are possible with sdasrab: 000000 3E 33 2 ld a,0x33 000002 FE 04 3 cp 4 000004 DD 7E FF 4 ld a,-1(ix) 000007 DD A8 5 sll 1, bcde which matches a little more what the Z80 programmers expect. It's already possible upstream in asxxxx (Edit: the principle for the implemented instructions, definitely not the >r2k instructions!) Note: I still haven't modified sdasz80 (which others would also need the modification to allow the same for all "Z80-like" generated code?)...
Starting from [r16246] the all following are possible with sdasrab: 000000 3E 33 2 ld a,0x33 000002 FE 04 3 cp 4 000004 DD 7E FF 4 ld a,-1(ix) 000007 DD A8 5 sll 1, bcde which matches a little more what the Z80 programmers expect. It's already possible upstream in asxxxx. Note: I still haven't modified sdasz80 (which others would also need the modification to allow the same for all "Z80-like" generated code?) as these specific changes (also upstream) are for each generated assembly operator instruction...
sdasrab: improvements, including '#'