[Coco] Gcc Cross compiler Win32 host - Progress.

[David]

On Tue, Nov 11, 2003 at 07:54:25AM -0500, John E. Malmberg wrote:
> David wrote:

> >>I now am hitting the expected error in building libgcc.a for mode
> >>DF.
 
> >I believe this is where the libgcc.a is needed.  DF is double float, and
> >it isn't defined.  This could be done as an RTL, I don't know.
> 
> The error is that the compiler needs to know the size attributes of 
> double type so that it knows how many bytes to place on the stack.  This 
> is defined in one of the *6809* files.

Yes, I had thought this could be a possibility.  I think I mentioned
that perhaps it could be defined in the md file.

> Once that is done, then probably a custom libgcc2.c will probably be 
> needed to supply the floating point routines.
> 
> I have been looking at the documentation for GCC and source of the other 
> platforms, and I have not found out how the DF "mode" as the compiler 
> calls it is generated.

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.
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...

> 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.

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.

> >Note that if you haven't already done that, to get it to compile, you
> >need to copy some of your coco headers over onto your system.  I just
> >made a directory coco/defs in my home directory and copied all my defs
> >directory into that.
> >
> >You should get an .o file that you can list out and see what it's doing.
> 
> Actually you get a .s file, and for the very small program that I did, 
> the .s file has the correct assembly code.

Yes, right.  an .o file is an object file.. like an .r file in OS9.

> But first I had to move some more .exe files into the CYGWIN .bin directory.

I just added gcc-3.1.1/gcc to my path.  It wouldn't have hurt to have
copied them into /bin but knowing that they were just rudimentary, I
didn't want them in there cluttering up the place.

> The assembler however is not able to interpret the code at all.  It is 
> complaining that every token on line is unrecognized.  So it appears 
> that some work there is needed.  It does not even recognize the comments.

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.

> But if all that is needed is to write a simple cross assembler, then 
> that will not be to hard.
> 
> >BTW, in your original post, you stated that you were limited in your
> >editor because of the CR-LF problem.  You can use Boisy's u2d, d2u
> >utilities to convert them back and forth.  One other thing.  Don't know
> >if this applies to cygwin or not, but mingw has two versions of make,
> >one for something and another for general compiles.
> 
> I am not limited in the CR-LF problem.

I meant with your editor choice.

> Some of the Microsoft Windows 
> tools can handle either format.  Notepad is one that can not.  wordpad, 
> otherwise known as write can handle just about any text format with out 
> conversion.  There are also a few editors in the cygwin suite.

Yes, I saw that wordpad worked.  If you are familiar with it, vi(m?) is
included with mingw, and probably cygwin, too.  The version I have with
MinGW doesn't function as well as the linux version - maybe it's not
configured right, but it does work.

> The use of write/wordpad will allow non-programming Windows users to 
> have an easy to use simple editor.

Yes, that's true, but I'd think that someone that has trouble with a
text editor wouldn't have much use for a compiler.  ;-)  Of course, I'm
not referring to what you said about notepad.  I tried it on some of the
readme's that came with MinGW and it was totally unusable - but found
that Wordpad did alright.