[Coco] Gcc Cross compiler Win32 host - Progress.

[David]

On Mon, Nov 10, 2003 at 12:50:56PM -0600, John E. Malmberg wrote:
> On Mon, 10 Nov 2003, David wrote:
 
> I do not know the minimum Cygwin parts that are needed.  That will take
> more research.  I grabbed what I thought would be needed and anything else
> that I though I might want.

I don't know, either.  I guess that will have to be done by trial and
error.  I've spent the afternoon playing with mingw and compiling the
gcc under it.  more later in the message...

> The failures were that the script did not have permission to update
> the global path environment variable, and did not update the local one either.

I take it that you are doing this on a work computer or something?  Is
the above related to the install of cygwin itself?  I don't understand
much about a setup like this.  It would appear that if you had authority
to install a program, it would install in such a way that you would have
permissions to access it.

> Most of the cygwin utilities can be used in a DOS cmd or command environment.

OK.  I was under the impression that cygwin programs had to be run under
a cygwin environment.

> The other issue is that inspite of trying to be complete, I missed getting
> parts that I needed.  This would have been bad if I did not have an internet
> connection where I was doing the build, and instead was using sneakernet.

There may be parts that just aren't available.  In trying to compile it
under mingw, mine aborted in a link stage where it had unresolved calls
to kill() and pipe().  I did try a make install and it aborted with the
same errors.  However, xgcc, cc1, and all had been created.  I added
gcc-3.1.1/gcc to my PATH and was able to get a little "hello world" to
compile to assembler source, however.

> I will probably go and download all of Cygwin, including source and burn it
> on a CD-ROM soon.
> 
> Note to potential non-technical volunteers:
> 
> There is a need to review these procedures to make sure they can be followed
> by someone with out a strong technical background and duplicate the results.

John,  one thing..

I take it you downloaded from the link on the skwirl web page?  I
grabbed the cvs repository on sourceforge. It seems to have some fixes,
at least, fixes not present in an earlier download I got from skwirl.

> > > The stock configure scripts were not able to determine the build host
> > > type.  It needed to be specified as --host=msdos, as this was the
> > > closest of the available choices.
> >
> > Are you doing all this from an MS-DOS command line?

> The configure scripts were run from the BASH shell provided by cygwin.
> 
> The problem is that the GCC maintainers apparently do not have the cygwin
> support in side the the global "configure" script, only inside the
> "gcc/configure" script.

I didn't have this problem.  The configure script identified my host and
build systems.  It did identify it as i686 and my stock Pentium should
have been i586, but it did make a guess at both.  There are two lines in
the configure output.. one for cygwin and another for mingw32 query.
Mine was correctly identified.

> It appears that the --host=msdos is being removed, and the cygwin is supposed
> to be replacing it, but the job is not done, and the 3.3.1 release is
> not compatable.  It may be that if I had started the the CYGWIN variant of
> the GCC 3.3.1 source, I would have had better results than with the
> official GNU distribution.

Were you using a "stock" gcc here?  Perhaps this is the problem.

> > > Some of the scripts were unable to create files in a temp directory
> > > created by the script.
> >
> > Reckon this was a permissions problem?
> 
> No, it is a bug in the tool that was trying to create the file.  Other
> tools had no problems creating the files.

Could this be in the permissions with which it was attempting to open
the file?

> > I found this out, too.  I reverted back to making under gcc-2.95.  Umm..
> > I just looked.  Some of the macros, like FUNCTION_PROLOGUE, have been
> > replaced by different names, in this case, TARGET_ASM_FUNCTION_PROLOGUE.
> > I don't know if I had changed this or not.  I don't recall if this was
> > one of them or not.  In this case, I believe they want you now to to
> > create an RTL for "prologue" in the machine description file.
> >
> > As far as simply commenting them out, I would assume that they will all
> > be needed in some form or another.
> 
> Actually they only need to be defined if they are different than what
> GCC will assume that they will have.  The ones that I checked were were not.

I didn't encounter this problem in compiling under mingw.  As I said
before, I first tried to compile under gcc-3.3.1 - and the compile
errored out because of the poisoning.  However, I believe at that time I
had, for instance, the macro FUNCTION_PROLOGUE rather than
TARGET_ASM_FUNCTION_PROLOGUE.  I notice that the cvs file has this
fixed.  My mingw uses gcc-3.2.1.  I got warnings about some
previously-declared macros being poisoned, but that's OK. A previously
declared something isn't destroyed if it is later poisoned.

> What I need to find out is why the double floating mode did not get defined,
> and the method of doing that has changed.

I believe that gcc does not internally define this, and it expects to
find it in libgcc.a, which we don't currently have.  It may be possible
to define it in the machine description file, I don't know.

> A similar method will be needed to get the "direct_page" mode to work.

This may take some work, I suspect that an extra reserved word may need
to be defined.  however, in studying the source, only 27 words in this
class are allowed, and all these spaces have been taken up.  We may have
to substitute this for some r.w. that another language is using.

Also, if we tackle OS9, the fact that the data area is separate from the
program area may take some doing.  I've been sudying some of the sources
for the OSK ports of gcc, and one or more macro definitions have been
introduced,and there are several places in the original gcc source where
these elements were added for various cases.

I don't think that either of these properties will be a simple
"drop-in".

> > > I posted something a little bit ago on the GCC-COCO-OS-9 list.  I have
> > > no idea how many are on that list.  I do not know if the archives are
> > > working.
> >
> > Where's this list?  Is there any activity on it?  I'd like to get it.
> > I've been trying to get a gcc-os9 compiler going but have not been
> > having much success.
> 
> The list is at the source forge link from:
> 
>  http://skwirl.ca/coco/gcc.html

Is this the gcc-coco sourceforge project?  It seems that I looked at the
forums in that project and there were not many entries.  Is there a
mailing list?

> > > I have mess also running on the Windows 2000 with COCO 3 and COCO 2 roms.
> > >
> > > I have not yet connected a virtual hard drive to it so that I can start
> > > running programs on it.
> > >
> > > I have not studied enough of MESS to be able to do this yet.
> >
> > Do you have Boisy's os9tools?
> 
> Not at this time.

These are great helps and quite useful.  They should compile on your
systems easily.

> >  I believe os9 format will format a HD,
> > too.. What I did was to simply copy over a vhd I had created under Jeff
> > Vavasour's emulator.  One caveat, though.  you may need to extend the
> > drive to its full size.  That is, when you first format the HD (and
> > virtual floppies, too, I believe the file itself is only what is needed
> > for the tables, etc.
> 
> As have not done much directly on a COCO hardware or emulator for years,
> I basically need the learn the instructions at a beginner level, like in
> a how to get started tutorial.
> 
> I do not know how to create a .VHD file.

I'm not sure.. you might even be able to just create an empty file and
just go into your emulator and format it and begin.  Again, I'm not
sure, but it still seems that mess - or some versions, at least, won't
extend a virtual disk if it's needed.  I do believe, however, that the
easiest way would be to grab the os9tools and use the os9 format
command.  (Assuming you want an os9 vhd)...

> I do not know how to put my files on it, or get them off.

Well, with an emulator, you simply copy files onto the vhd.  Also, with
the os9tools, you can add them, too..  there's an os9 dsave, as well as
copy, makdir(?)..

> And when I get my SuperIDE card, with the CompactFlash that I should be
> able to use on both the COCO and the PC, I do not know how I will transfer
> files.

I know it's "sneakernet", but if your coco has a floppy your vms system
can read (i.e. if your coco has a 3.5" drive, or your VMS has a 5.25),
then the linux "fdutils" will do a neat job.  With it, you can set the
drive to the SPT, TRK# of the coco disk, and then dd to/from a virtual
floppy disk file, or you can even access the disk directly with
os9tools.

> I barely remember COCO commands, let alone Flex-09 commands, or OS-9 shell
> commands.

I'm sure they will come back.

> > > On my system, the MESS COCO only seems to run full screen, I have not
> > > yet managed to get it to run in a window.  VNC is not able to serve it
> > > well for remote access.  Keystrokes are lost.
> >
> > Mess seems to take quite a bit of CPU power.  I only have a P-166 and
> > xmess is practically unusable - and that's at the console, not remote.
> 
> It seems useable on my 266 Mhz Pentium.  VNC almost worked.

This is xmess under linux.  But the extra 100 Mhz would do a lot, too.

> I may try my hand at my own COCO emulator written in C for X-11/MOTIF or a
> VT340/REGIS platform.  A VT340/REGIS implementation would allow it to be
> accessed from a TELNET session.  The O.S. I would be testing it on would be
> OpenVMS.

This might be a good thing.  We do have some good emulators for windows,
but operating under linux on these slower systems would be greatly
enhanced, I believe, with an emulator strictly dedicated to emulating a
coco.

> Getting a cross compiler working right now would be more useful though.

Yes.  It certainly would.  But there seems to be quite a bit of work
ahead.  Actually, sometimes I think that it would be just as easy to
write a compier from scratch.  It's pretty difficult to go into a
program as big as gcc and try to figure out what "they" did and try to
make something work within that framework.