Concerning 'multiple ..... at address 0x00'

[This N°9]

Some of you may remember the 'multiple whatever at address 0x00' - issue (the SDCC compiler bug). I just realized what's all about the 0x00 story: (I learned this while looking at the MIOS-wrapper)

MIOS places some registers for the OS at memory address 0x00, the SDCC wrapper uses this address *also*, but declares them as 'overlay' (shared), it uses them as function params:

; Internal registers
.registers	udata_ovr	0x0000
r0x00	res	1
r0x01	res	1
r0x02	res	1
r0x03	res	1
r0x04	res	1
r0x05	res	1
r0x06	res	1
r0x07	res	1
r0x08	res	1
r0x09	res	1
r0x0a	res	1
r0x0b	res	1
r0x0c	res	1
r0x0d	res	1
r0x0e	res	1
r0x0f	res	1
r0x10	res	1
r0x11	res	1

I thought 'oh my god', but the good thing is, that these internal registers will be pushed and popped to/from the stack at every function call/return. So if the program goes back to the main loop, the original values will be there again.

I just wonder what happens if I call a MIOS function that sets a flag or so in one of these registers. This value would evetually get lost on the way back to the main loop ?

[stryd_one]

If you write an app that uses these SDCC internal registers, you'll see in the output:

; Internal registers
.registers udata_ovr 0x0010 ;; normaly 0x0000, changed by mios-gpasm
r0x00	res	1

In /trunk/bin/mios-gpasm (a shell script) you can see where this is done:

    sed \
      -e 's/^\.registers.*udata_ovr.*0x0000/.registers udata_ovr 0x0010 ;; normaly 0x0000, changed by mios-gpasm/g' \

:D

That error was appearing because when SDCC was broken, it wasn't calling that shell script

[This N°9]

Ah yeah... Simmilar issue as with the FSR1/0 swap..

By the way: I use now FSR1 / MIOS_PARAM_1 / MIOS_PARAM_2 in my module to pass parameters to the functions.. Do I go right assuming that MIOS_PARAM_1 / 2 are exactly there for this purpose? First I was not sure if it is 'legal' for modules to use them, but I see that the AIN-module for ex. also uses them as function params.

I start loving ASM, it's really hitting the bottom (or top) of the whole coding story... joy  :D

[stryd_one]

By the way: I use now FSR1 / MIOS_PARAM_1 / MIOS_PARAM_2 in my module to pass parameters to the functions.. Do I go right assuming that MIOS_PARAM_1 / 2 are exactly there for this purpose?

Yeh pretty much.

Generally speaking, if you intend the module to be used in ASM apps, I would pass the first byte in W, and subsequent bytes in PARAM1/2/3 etc. That keeps it in the convention that TK has started.

If you use __wparam in your C declaration, then SDCC will put the first parameter in WREG for you, and the subsequent bytes will be in FSR0. Then in your wrapper .asm file, copy to PARAMx from FSR0, via FSR2, where required.

I put examples in the mod_skel, this one's modified to match the description I just gave:

; EG: void mod_skel_function(unsigned char myvar, signed int myint) __wparam;

; not required, it's already in W 	
; 	movwf	_mod_skel_var		; get first byte of arguments from W

 	movff	FSR0L, FSR2L		; get other arguments from stack
 	movff	PREINC2, MIOS_PARAMETER1
 	movff	PREINC2, MIOS_PARAMETER2

[This N°9]

That's exactly what I intended to do  :) FSR1 I'll use for data buffer address pass, MIOS_PARAM_1/2 for chip memory address pass. Stuff like buffer size / chip select I pass via WREG.