PDK13

[cpldcpu]

I ported SDASPDK to PDK13, see zip file:

SDASPDK13.zip

As mentioned before, I have no idea how to integrate this into SDCC/SDAS without creating a completely new architecture. I hope it's useful.

[spth]

There are two options to make pdk13 live beside pdk14, as can be seen in the handling of other architectures in sdas:

1. Separately. E.g. The asrab is different from asz80 despite these architectures being rather similar.
2. Combined. E.g. The asz80 assembler also handles the eZ80. When there is an .ez80 in the asm file, the assembler switches to eZ80 mode.

Since I never ported the assembler to a new architecture myself, I do not know which one is more appropriate in this case. However (apart from the asrab vs. asz80 case), typically, the first option has been chosen when binary encodings were different, while the second option has been chosen when the binary encodings were mostly the same, with one instruction set being mostly a superset of the other.

Philipp

[cpldcpu]

The structure of SDAS does not really lend itself to dynamic encoding of mnemonic. E.g. all instruction encodings are defined via a struct at compile time.

Probably it is indeed the easiest way to have separate binaries for pdk13/14/15/16. Looks messy though, and difficult to maintain.

[Rakete1111]

I think separate assemblers is the way to go, since they are pretty much different. However, it seems like we can make the code better with less duplication by using a common fundamentation if that makes sense.

[spth]

The pdk14 assembler source has been reorganized in the SDCC source tree. This should make it easier to get the pdk13 variant in as a separate assembler, so in the future, SDCC would be able to support both.

P.S.: cpldcpu, can you prepare such a version of your pdk13 assembler?

[Rakete1111]

@cpldcpu The non-pdk14 specific parts have been moved to aspdk/, so creating the new assembler should be more straightforward than it was before.

[spth]

While we don't have a simulator yet, pdk14 seems to work okay now (though I'm sure there are many bugs hiding in some corner cases in the compiler that will be found once we have the simulator). While I din't check as closely, I assume pdk15 is doing similarly well.

Fortunately, compiler bugs should be about the same across pdk13, pdk14, pdk15, so when Nicolas has the simulator for pdk14 ready, we can find practically all bugs affecting any of the 3.

If the pdk13 assembler and linker are ready (i.e. at the level of pdk14 and pdk15) within the next 2 weeks or so, all 3 might make it into the 3.9.0 SDCC release.

Philipp

[cpldcpu]

One stupid question: How do I add pdk14 to the automake configuration?

[spth]

Do you mean pdk13? pdk14 is already there (in the pdk branch).

There are lines AC_CONFIG_FILES([sdas/aspdk14/Makefile]) and AC_CONFIG_FILES([sdas/aspdk15/Makefile]) in configure.ac. Add AC_CONFIG_FILES([sdas/aspdk13/Makefile]) in the right place, and update the configure by invoking autoconf.

Philipp

[cpldcpu]

pdk13, yes. Thanks! will look into it!

[cpldcpu]

Btw, I noticed that the code density suffered a bit in the latest releases:

• "set1 io,1" is not inferred anymore from "pa|=0x01". Strangely enough this works for set0 with pa&=~0x01

                                173 ;	blinky.c: 28: pa|=0x01;
  000090 D0 01                  174 	mov	a, _pa
  000092 01 2D                  175 	or	a, #0x01
  000094 90 01                  176 	mov	_pa, a
  

• "while (--counter);" is generating code that uses a temp memory position for some reason. This was not the case earlier, afair.

                                157 ;	blinky.c: 27: while (--counter);
  000074                        158 00104$:
  000074 82 0F                  159 	mov	a, _counter+0
  000076 01 29                  160 	sub	a, #0x01
  000078 86 0B                  161 	mov	_main_sloc1_1_0+0, a
  00007A 83 0F                  162 	mov	a, _counter+1
  00007C 61 00                  163 	subc	a
  00007E 87 0B                  164 	mov	_main_sloc1_1_0+1, a
  000080 86 0F                  165 	mov	a, _main_sloc1_1_0+0
  000082 82 0B                  166 	mov	_counter+0, a
  000084 87 0F                  167 	mov	a, _main_sloc1_1_0+1
  000086 83 0B                  168 	mov	_counter+1, a
  000088 86 0F                  169 	mov	a, _main_sloc1_1_0+0
  00008A 87 0E                  170 	or	a, _main_sloc1_1_0+1
  00008C 00 2A                  171 	ceqsn	a, #0x00
  00008E 3A 30                  172 	goto	00104$
  

[cpldcpu]

I encountered a slight issue when porting the assembler to PDK13: the SET0/SET1 M,#x instructions seem to encode the memory address shifted by one bit to the left.

Looking at how relocatable addresses are handled in sdcc, it seems that this is not supported in the existing code in asout? (e.g. out_lxb) .

Also, it seems that mask is not applied to the relocated address, right? In that case it may be possible to generate invalid instructions after relocation for some of the opcodes that only support a subset of the memory addresses, e.g. Setx. This does also apply to PDK14/15.

[Rakete1111]

Looking at how relocatable addresses are handled in sdcc, it seems that this is not supported in the existing code in asout?

Yeah, not really. The linker also doesn't support it. This is another special case that the linker will need to handle :/ Those are also the only instructions that use this format, great. Let me see if it's even possible to support this in the existing linker. Probably is though.

Also, it seems that mask is not applied to the relocated address, right?

Yes-ish. 0xFFFF is applied, but since every instruction uses a different address mask, I don't see how the linker can support this effectively. That specific case you mentioned is pdk13 specific, but the general problem does exist for pdk14/pdk15. There is a related problem for instructions that take word-aligned memory.

[cpldcpu]

That specific case you mentioned is pdk13 specific, but the general problem does exist for pdk14/pdk15. There is a related problem for instructions that take word-aligned memory.

Actually there are some instruction on the PDK14/15 that only support a subset of the total memory space. For example Set0/1 only support a 6 bit address and can therefore only be used on the first half of the memory. How does the linker know not to exceeed this address space?

[Rakete1111]

How does the linker know not to exceeed this address space?

It doesn't as of right now :). You'll just have to be careful. I can implement some sanity checks, like no address can exceed 12 bits, but not more unfortunately.

[spth]

It would be good to have a warning from the linker when an address is outside of the range that an instruction supports (e.g. an address that is too large for set0, or a non-aligned address for idxm). But this feature doesn't look like top priority to me for now.

Philipp

[cpldcpu]

The easiest workaround right now is probably to omit generation of Set0/1 with memory as a target. This should not be a very frequently needed op anyways. Set0/1 is mostly relevant for I/O and there should be no relocation issues there.

[spth]

I can implement that workaround for pdk13 in SDCC. Then set0 and set1 would be used for pdk14 and pdk15 only.
However, in the long term, we'd want set0 and set1 support in the assembler; even if SDCC does not emit them, people writing assembler code will expect it.

Philipp