> I doubt anyone will try to directly compile a linux program or even an old
> DOS program for the MSP.
That's the sort of assumption I'm not willing to make. There's a lot
of working code out there, and a definite value in portability and
conforming to what the C and C++ languages require regardless of
platform.
My goals are:
* Optimize for the common case
* Provide freedom for the application developer to implement the
uncommon case without having to modify the toolchain
* Limit the maintenance issues that come from hard-coded special cases
in the compiler
I've found an acceptable (to me) solution in the distinction between
freestanding and hosted implementations of C/C++. So what I'll do is:
* Add a new linker section .main between .init9 and .fini9
* Treat what gcc determines is the application entrypoint (nominally
"main") as though it were declared with:
__attribute__ ((naked,section(".main")))
which means there will be no function prologue or epilogue and
execution will fall into main after init and into fini after main.
* Do some sort of validation on the return type and parameters to
main() to ensure the user is warned if they're doing something bogus
(like accessing the uninitialized argc parameter).
This is all consistent with the notion of a free-standing
implementation, and gets you your default optimal behavior.
Conceptually, if the application entrypoint is explicitly declared with:
__attribute__ ((hosted))
then all that special case handling will be avoided, main will have a
prologue and epilogue, any declaration that passes the language
binding specification will be allowed, main will be put in .text, and
it will be the developer's responsibility to stick something in the
.main linker section that prepares the arguments, calls main, and
processes the return value. This might be valuable when creating a
hosted framework: for example, something like Contiki that supports
the same code running on different microcontrollers, with MCU-specific
operations abstracted into library routines.
Yes, the whole effect of "hosted" can be obtained by just renaming the
"real" main function and doing the prep and call in the freestanding
main, but that can get messy and impacts the ability to create hosted
frameworks that implicitly support MSP430s. As long as the
maintenance impact is as small as I think it will be, I'd rather
support the pattern explicitly than have everybody who needs it have
to implement it on their own.
> Of course proper documentation is required for any implementation.
> And with 'proper' I don't mean a one-liner in the mspgcc source code,
> but rather an exhaustive explanation in a real manual that's available
> without Wiki, mailing list or digging through repository reports.
There is in fact a real manual for mspgcc, in docbook format, which
I've placed in the mspgcc git repository and am slowly bringing up to
date as I make changes. The original version is on the web at
http://mspgcc.sourceforge.net/manual/, and it should be easy to put
the generated html and even pdf versions into distributions.
Peter
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Mspgcc-users mailing list
Mspgcc-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mspgcc-users
