Hi Peter,
This is amazing work. I am very excited for 20bit support in mspgcc.
After reading the document I want to ask what may be an extremely out-there
question:
I gather that most people who require far code support should use the compiler
options -mc20 and -msr20. I am not sure how wasteful the __sr20__ attribute on
all functions will actually be, but it feels like a waste of RAM if say less
than 5% of functions actually make use of 20bit registers (am I correct in
saying, in general, only functions which perform pointer arithmetic on function
pointers will generate 20bit register values? [ignoring far data pointers and
explicit use of 20b integer types]).
Could it perhaps be more efficient (overall) for a function which makes use of
20bit values in registers to save its own 20b registers before calling a
function which could potentially overwrite them?
Eg.
uint16_t vals[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9,
0x8001, 0x8002, 0x8002, 0x8004, 0x8005,
0xf000 };
/* ... */
{
uint20_t sv;
sv = 0;
for (i = 0; i < sizeof(vals)/sizeof(*vals); ++i) {
sv += vals[i];
// BEFORE CALLING PRINTF (OR ANY FUNCTION WHICH IS NOT KNOWN TO BE
__sr20__) THE COMPILER/ASSEMBLER CAN LOCALLY SAVE ANY 20b REGISTERS HERE
printf("Add %04" PRIx16 " produces %05" PRIx20 "\n", vals[i], sv);
// ON RETURN FROM FUNCTION 20b REGISTERS ARE RESTORED
}
}
I am not saying we should change the calling convention - all functions still
save and restore 16b registers in their prologues and epilogues as required. I
am just thinking that the compiler could automatically detect which registers
are 20bit and need to be saved using pushx.a/pushm.a instructions and do the
save/restore locally (before pushing and after popping any stack based function
parameters). There is every chance that the registers themselves will not be
modified, which means that the 4 bytes of storage are wasted for each register.
If they *are* used by the called function (or one of its called functions) they
will be saved twice (or more times), which uses slightly more storage than
necessary. I wonder if overall this could be beneficial in a program where in
the vast majority of the time 20bit registers are not used and thus the
__sr20__ attribute on ALL functions could be wasteful. Also it means that an
__sr20__ multilib would not be required.
Just an idea, I can only assume that this functionality would be possible to
implement - whether it is a good idea or a bad idea I leave up to you.
- Wayne
-----Original Message-----
From: Peter Bigot [mailto:big...@acm.org]
Sent: Friday, 27 April 2012 7:31 AM
To: GCC for MSP430 - http://mspgcc.sf.net
Subject: [Mspgcc-users] Draft 20-Bit Design/Interface Specification available
for review
The first draft of the design specification for 20-bit support in
mspgcc has been added to the wiki at:
https://sourceforge.net/apps/mediawiki/mspgcc/index.php?title=Gcc47:20-Bit_Design
Interested parties are invited to read the document on the wiki, and
comment on this mailing list.
The specification focuses on the atomic capabilities which combine to
form what's normally called a "memory model". They are highly
orthogonal, although some combinations are likely to result in
unexpected (i.e., buggy) behavior.
I specifically invite comment on exactly what memory models should be
supported by roll-up options that enable/disable the individual
features described on that page, and what compiler option will
identify them. (It'd be something like "-mmodel=large", but what
exactly should "large" mean?) Preferably the naming and semantics of
these models should tie back to existing practice in other MSP430
toolchains or other GCC back-ends.
At this time, I believe what's described is technically possible, but
the management of the namespaces, correct specification of pointer
types based on code and options, and exactly how to get the linker to
assign data and function objects into the split address space are yet
to be implemented, and some showstopper issue might arise. (As far as
I can tell nobody's ever made binutils support a split address space
before. Getting 20-bit integers to work produced five bug reports
against upstream gcc so far, all of which have been fixed in mspgcc
with at least one already fixed upstream as well.)
Peter
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
