[comp.sys.3b1] cross compiling ?

jms@informix.com (John Stephens) (03/07/91)

I heard an interesting rumor that some of the more esoteric switches available
in the Sparc Station compiler (notably the 68000 code generator) code be used
to build code that would execute on the 3b1.

This would make the building of some of the larger GNU sources possible, to
say nothing of speeding up the build time.

Can it be done ?  Have you done it ?

Thanks

Jack
-- 
 -------------------------------------------------------------------------
| Jack Stephens      ..!{uunet|pyramid}!infmx!jms --or-- ..!jack!wzlr!jms |
| Systems Programmer "Into the valley of Death rode the 600...            |
| Informix Software      which allowed them to use the carpool lane."     |

clewis@ferret.ocunix.on.ca (Chris Lewis) (03/09/91)

In article <jms.668278528@wits-end> jms@informix.com (John Stephens) writes:
>I heard an interesting rumor that some of the more esoteric switches available
>in the Sparc Station compiler (notably the 68000 code generator) code be used
>to build code that would execute on the 3b1.

>This would make the building of some of the larger GNU sources possible, to
>say nothing of speeding up the build time.

>Can it be done ?  Have you done it ?

I haven't done it in this particular context, but I have done similar
things (eg: object module format conversions to permit execution
of NCR tower binaries on 68020 Xenix systems...).  The 68000 ABI is
actually pretty standard - surprised the hell out of me that NCR's SVR2
system call conventions were identical to (incredibably archaic LISA!)
Xenix.

It'll probably work.  Provided that the Sparc (or whatever) generates
a compatible COFF format file, and that the function calling convention
is the same (this only for the main function).  If the latter isn't true,
a rewrite of crt0.o will fix things so that argc, argv and envp get in
to the main function properly.  (Not hard - disassemble and add
a bit)  Things to watch out for: inlining of system calls (yipes!) - but
even that would work as long as the system call convention was the same.
Another: some systems have the function prologs do pokes to
memory to ensure that stack gets allocated - you may have to fake that
somehow if the 3b1 needs it - though I think some of the old Suns needed
it too.

You'll probably also have to copy over the include files and libraries if
you want to do the link on the Sparc.  The 3b1 has lots of non-SVID stuff.
I doubt you could do links with the shared library, but you might.  Or,
postpone the link to the 3b1.

-- 
Chris Lewis,
clewis@ferret.ocunix.on.ca or ...uunet!mitel!cunews!latour!ecicrl!clewis
Psroff support: psroff-request@eci386.uucp, or call 613-832-0541 (Canada)

thad@public.BTR.COM (Thaddeus P. Floryan) (03/11/91)

In article <jms.668278528@wits-end> jms@informix.com (John Stephens) writes:
>I heard an interesting rumor that some of the more esoteric switches available
>in the Sparc Station compiler (notably the 68000 code generator) code be used
>to build code that would execute on the 3b1.
>
>This would make the building of some of the larger GNU sources possible, to
>say nothing of speeding up the build time.
>
>Can it be done ?  Have you done it ?

Dunno about the Sparc, but about every 6 months I post my offer to compile
"large" programs on my Miniframe which has a 3.5MB address space (contrasted
with the 2.5MB space on the 3B1).

No charge for the service IF all postage/packaging charges are pre-paid.

Am still looking for the software with which to operate the Ethernet port on
this baby; actually it's running Motorola's FE07 OS, but it otherwise appears
identical to CTIX and everything I've compiled/linked on it to date DOES run
just fine on the 3B1.

And if I ever find the time to rebuild an old MightyFrame which is sitting in
my garage in pieces, compiles would be even easier and faster (since it's a
68020-based system, otherwise compatible to the 3B1).  The reason it's in
pieces is due to what I claim is a design flaw: the cables to the HDs get
pinched and pierced by the case ... thus /dev/rfp000 went belly up when some
cables got grounded while writing to the HD and the superblock went POOF;
luckily everything's backed up on tape, but I don't have the software to
reformat the HD ... no floppies on this machine, everything is to/from tape.

Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]