Re: [sdcc-devel] [ sdcc-Feature Requests-934090 ] sfr16, sfr24, sfr32

[Maarten B. (sourceforge) <sou...@ds...>]

>
>> Submitted By: Maarten Brock (maartenbrock)
>> Summary: sfr16, sfr24, sfr32
>>
>> After thinking about the sfr's some more, I think
>> constructs for 16 bit, 24 bit and 32 bit sfr's would make
>> life easier as well. I also think the compiler can use it to
>> it's advantage in creating compact code. But it must be
>> a bit better than what Keil implemented for sfr16. They
>> only understand adjacent addresses for the two bytes.
>> In my opinion the declaration of a multibyte sfr must be
>> declared using multiple addresses like this:
>>
>> sfr at 0x8A TL0; //timer  low byte
>> sfr at 0x8C TH0; //timer  high byte
>>
>> sfr16 at 0x8A,0x8C T0; //timer 0
>>
>> This shouldn't create a problem since sfr's cannot be
>> addressed indirectly anyway.
>
> On the 8051 and its derivatives, the sfr's cannot be addressed indirect=
ly,
> but they can on the z80 (although currently SDCC gets confused by this
> since it has no pointer to sfr type).

If we do not accept the keywords sfr16 and sfr32 for z80 than it will not
create a problem, but also no extension to this port ;-) I'm focussing on
mcs51 for now.

> Perhaps not typical(?) 8051 C coding style, but it is currently legal t=
o
> declare
>
>   sfr at 0x8A TL0;
>
> in only one source file and then
>
>   extern sfr TL0;
>
> in other source files with the linker resolving the address. A
> non-contiguous allocation would make this harder to resolve.

Not really. My implementation stores all 8bit subaddresses in the one and
only 32bit address field. aopGet and aopPut (mcs51/gen.c) need info about
accessing sfr or not (replaced aop* by operand*) and instead of using
(TMR0+offset) as the address it takes (TMR0 >> (8*offset)) if it's dealin=
g
with an sfr.

> Your originally proposed syntax might need to be changed. Since the "at=
 x"
> notation is actually part of the type, it is syntactically valid to
> include it in a function prototype where commas are also seperating the
> types of the parameters. Although not totally ambiguous, this might
> require a deeper lookahead than a yacc's generated parser can handle.
>
> Your second syntax, with all the addresses combined into a single value=
,
> would take care of both of these problems, at least for the 8051. It wo=
uld
> be nice to find something a bit more elegant, though.

Again, I need help with that. I know my solution is not very elegant, but
it sure works. Would parentheses help? Or do you have a better idea? If n=
o
elegant solution comes up, maybe we should just continue and accept that.

> My inclination at
> the moment would be to leave non-contiguous variables for the programme=
r
> to explicitly deal with and make SDCC's implementation of packing and
> unpacking bytes to/from larger types more efficient.

But there are so many non-contiguous 16 bit sfr's. I agree that
packing/unpacking asks for more efficiency.

>> With the Silabs C8051F120 which has a 16x16 MAC and
>> C8051F350 which has a 24 bit ADC, sfr24 and sfr32 are
>> welcome as well. Maybe other chipvendors have similar
>> long sfr combinations as well.
>>
>> Then there is the problem of the access sequence. For
>> some sfr combinations it's best to access them low byte
>> first, for others it's high byte first (latching, starting
>> conversion). (This is even true within one mcu) Maybe
>> this can be set by some special keyword. On the other
>> hand, maybe this is asking too much.
>
> I think a user specifiable access sequence really needs to be supported=
.
> Otherwise, what is the advantage of declaring a multi-byte register as =
a
> single variable if the compiler generates the accesses in the wrong ord=
er?

Not all multi-byte registers need a specific order. Some do and that is
what I want to let the programmer explicitly deal with (for now).

> We also need to make sure iTemps are generated, if needed, so that
> operations such as addition and subtraction that must operate in lsb to
> msb order are suitably buffered from objects that require msb to lsb
> accesses.
>
>    Erik

Good point, extra reason to stay out of this area for now.

B.t.w. I think I will drop the sfr24 idea. It's comes with too many extra
problems. I already asked SiLabs if they have a spare dummy sfr that
always reads 0x00 and ignores writes so one can implement the adc
registers as sfr32 but alas, there is none. Remaining option is to leave
this to the programmer who can either just access the separate sfr's or
mask the data interchanged with the sfr32. Some things are just out of
reach.

Anyway, thanks for the reply and please help if you can.

Maarten