[Coco] Gcc Cross compiler Win32 host - Progress.
John E. Malmberg
wb8tyw at qsl.net
Wed Nov 12 00:40:00 EST 2003
David wrote:
> On Tue, Nov 11, 2003 at 07:54:25AM -0500, John E. Malmberg wrote:
>
>
> Umm.. one thing.. I believe one of the defines in the .md file has
> something to do with a "SFMode", but no simple "SF", as I recall.
That is what I have been unable to find.
The GCC folks have changed how this is implemented, and the
documentation has not been updated to reflect this change.
> Perhaps a similarly styled definition for "DFMode" might do the trick.
> As a test, one might simply copy that define for the SF mode and change
> it to DF. Of course it wouldn't be correct without changing the calls,
> etc, but if that would get rid of that error, it could be fixed later.
> Right now, it would just be nice to get it to compile completely...
It appears that mainly what the compiler needs is the size of the type,
and then it will need the library calls.
It all looks like some simple line is missing or is present and should
not be that is preventing the compiler from generating the needed
default handler.
>
>>I may have to go backwards from the generated file that is missing the
>>definition, and figure out what tool is used to generate it.
>>
>>The attributes for the internal types are represented by something
>>similar to an internal compiler __mode__(xxxx) directive.
>>
>>This is the same way that a direct page attribute would be implemented,
>>in the *6809* file, you define the instructions that are generated for
>>accessing a direct page value. But the __mode__(direct_page) or
>>equivalent, would also have to have a way to specif
>
>
> I have a feeling it may take a bit of hacking to get "direct"
> implemented. There may be a simpler way of getting it installed, but I
> am thinking that it will need to be added to the reserved word list.
GCC has a mechanism for this, __attribute__(x), where x is something
that should be definable.
You then do a:
#ifdef __M6809
#define direct_page(value) __attribute__(direct_page, value)
#else
#define direct_page
#endif
Now for a direct page mode, not only variables have to be taged as a
direct_page, the specific direct page that they are a member of needs to
be specified.
The __mode__() directive is something similar to __attribute__(). The
compiler uses this information along with the *6809* files in some way
to select what code is to be generated.
> As far as the data variables are concerned, there _may_ be a relatively
> simple way of doing this. There's mention of at least one field (I
> think it's a bit field - maybe with the name volatil or something like
> that - that's reserved for user definitions. Perhaps it might be used
> as a flag that it's data. Of course, that's for OS9, but I believe this
> is your goal, too. To be honest, I don't think it would be much problem
> (except for maybe the "direct" thing) to implement a working RSDOS
> compiler.
volatile is one that I can see that I may have a need for, especially
for OS-9 programming.
My goal is to get something that will compile C code for the following
targets:
1. Standalone COCO with a library that may optionally call ROM routines.
2. OS-9
3. FLEX-09.
> I hadn't even tried to use the assembler. I'd still like to stick with
> rma/rlink, at least for OS9, but it might be simpler to start working
> with this combination. At least we have the source to go with.
I have never actually been able to build any programs on OS-9, so I am
not familiar with those tools.
I may not have time to do much more investigations until this weekend,
and I am hoping to find the piece of information that will tie this all
together.
-John
wb8tyw at qsl.net
Personal Opinion Only
More information about the Coco
mailing list