Janko Stamenović

As far as I've seen, SDCC is already able to generate more less code for switch for some code inputs (seen on Z80) avoiding unnecessarily creating the table and using it (which we see is an order of 80T per choice) when just doing a few compares and conditional jumps is reasonable: I've seen that for the switch on unsigned char variable (a snippet): 134 ;printf_small_mod.c:84: switch (c) { 00000065 7C [ 4] 135 ld a,h 00000066 FE 58 [ 7] 136 cp a,#0x58 00000068 28 34 [12] 137 jr Z, 00112$ 0000006A...

As far as I've seen, SDCC is already able to generate more less code for switch for some code inputs (seen on Z80) avoiding unnecessarily creating the table and using it (which we see is an order of 80T per choice) when just doing a few compares and conditional jumps is reasonable: I've seen that for the switch on unsigned char variable (a snippet): 134 ;printf_small_mod.c:84: switch (c) { 00000065 7C [ 4] 135 ld a,h 00000066 FE 58 [ 7] 136 cp a,#0x58 00000068 28 34 [12] 137 jr Z, 00112$ 0000006A...

As far as I've seen, SDCC is already able to generate more less code for switch for some code inputs (seen on Z80) avoiding unnecessarily creating the table and using it (which we see is an order of 80T per choice) when just doing the a few compares and conditional jumps is reasonable: I've seen that for the switch on unsigned char variable (a snippet): 134 ;printf_small_mod.c:84: switch (c) { 00000065 7C [ 4] 135 ld a,h 00000066 FE 58 [ 7] 136 cp a,#0x58 00000068 28 34 [12] 137 jr Z, 00112$ 0000006A...

IMO, SDCC should not consider the MSX-specific timings. Also you should definitely not trust https://msx.jannone.org/bit/ because it wrongly counts 3 bytes for JP (HL) when it is a single byte, in fact! The correct size of the "old" code is 12 bytes, as in the listing I've given, you can count the bytes there. Moreover, the sdasz80 which is a part of SDCC will also produce a LST file with the T timings and the bytes of each instruction, it just doesn't sum them. Here's the correct lst made by sdasz80:...

IMO, SDCC should not consider the MSX-specific timings. Also you should definitely not trust https://msx.jannone.org/bit/ because it wrongly counts 3 bytes for JP (HL) when it is a single byte, in fact! The correct size of the "old" code is 12 bytes, as in the listing I've given, you can count the bytes there. Moreover, the sdasz80 which is a part of SDCC will also produce a LST file with the T timings and the bytes of each instruction, it just doesn't sum them. Here's the correct lst made by sdasz80:...

IMO, SDCC should not consider the MSX-specific timings. Also you should definitely not trust https://msx.jannone.org/bit/ because it wrongly counts 3 bytes for JP (HL) when it is a single byte, in fact! The correct size of the old code is 12 bytes, as in the listing I've given, you can count the bytes there. Moreover, the sdasz80 which is a part of SDCC will also produce a LST file with the T timings and the bytes of each instruction, it just doesn't sum them. Here's the correct lst made by sdasz80:...

IMO, SDCC should not consider the MSX-specific timings. Also you should definitely not trust https://msx.jannone.org/bit/ because it wrongly counts 3 bytes for JP (HL) when it is a single byte, in fact! The correct size of the old code is 12 bytes, as in the listing I've given, you can count the bytes there. Moreover, the sdasz80 which is a part of SDCC will also produce a LST file with the T timings and the bytes of each instruction, it just doesn't sum them.

I've checked with zmac (1) which I like because it also sums the T states, and the sizes could be read from the addresses): In the first case, the fixed code is 12 bytes (00C at the L1 point ) in the first case, then it needs 3 bytes per each table entry, and the execution is 83 T (73+10 after a jump is executed). 6: 0+19 8000 FD4E00 ld c, 0 (iy) 7: 19+7 8003 0600 ld b, $00 8: 26+10 8005 210C80 ld hl, L1 9: 36+11 8008 09 add hl, bc 10: 47+11 8009 09 add hl, bc 11: 58+11 800A 09 add hl, bc 12: 69+4...