🚀 go-pugleaf

  hello,

 here are the answers I received from my previous post :

> just wondering if someone has begun porting GCC (and GAS)
> to the R4000 series of processors in 64 bit mode. I know
> it is possible to switch the processor to run in 32 bit
> mode (same instruction set as R[23]000 familly), but I
> would be interested to have long and pointers encoded in
> 64 bits. Any remarks or suggestions concerning the way
> to make the porting easier would be great !



I] GCC doesn't currently support R4000 in 64 bits mode
(32 bit mode is supported since it restricts the instruction
set to Mips1, used for exemple in the Decstations for which
support is available). And since there is no 64 bit OS for
R4000 currently available a 64 bit compiler would be of no use ...

rex@cs.su.oz.au (Rex Monty di Bona)
>  If this is to run on a RISC/OS box, then RISC/OS 5.01 doesn't
> support the 64bit mode...

mccauley@phaeton.wpd.sgi.com (Jay McCauley)
>You would also need considerable OS support to use the resulting
>binaries.  We have 64 bit kernels running in the lab (well,
>running is kinda strong, walking with a limp is probably a more
>accurate description ;-)).  The first systems supporting this
>will be the previously announced Power CHALLENGE, some time in
>1st half of 1994.  This is a major project, as there are way
>too many places that make tacit assumptions about the size of
>various data items.

davea@quasar.mti.sgi.com (David B.Anderson)
>It's not just a compiler issue.
>
>You have to be running a kernel that saves and restores registers
>properly for 64-bit applications to work.   In other words, the
>kernel must be modified to recognize the extra registers and the
>extra register bits.
>
>No shipped IRIX does this, so you cannot run true 64-bit applications
>on any shipped IRIX machines.  RISCos is also 32-bit I believe.
>
>You will have to wait a bit.



II] it seems that a lot of people would be interested in 64 bits
application and compilers :

rvenkate@epsiii.enet.dec.com (Ravikumar Venkateswar)
>> If this is to run on a RISC/OS box, then RISC/OS 5.01 doesn't
>> support the 64bit mode...
>>
>
>Ya know, this is one of the things that's keeping me from really
>looking at using the R4000 series. Not everybody runs RiscOS. In
>fact, a goodly number of people in the embedded market are NOT
>running RiscOS.
>
>For the sorts of embedded applications I do, I'm not really running
>any OS at all.
>
>I can't fathom why Mips/SGI doesn't feel an urgent need to get a
>cross supporting compiler out that supports 64bit mode.



III] Good news, some kind people are going to make a port of GCC
for Mips R4x00 in 64 bit mode. Algorithmics should deliver soon
a commercial environment for developping 64 bit apps. ont R4000 ...

ian@airs.com (Ian Lance Taylor) :
>Cygnus Support is going to be doing this work over the next several
>months, which will be contributed back to the gcc sources (Cygnus is
>already the gas maintainer). ...

Jim Wilson <wilson@moria.cygnus.com> :
>> just wondering if someone has begun porting GCC (and GAS)
>>to the R4000 series of processors in 64 bit mode. I know
>
>I will be doing some gcc/r4000 development.  I don't know how
>much of the 64-bit port I will attempt though.  It will probably
>be a lot of work to properly support the r4000 64-bit mode in gcc.
>
>>it is possible to switch the processor to run in 32 bit
>>mode (same instruction set as R[23]000 familly), but I
>
>Every one I have seen already runs in 32 bit mode.
>Finding one that is running in 64 bit mode is the hard part.
>
>There is no publicly available 64 bit OS as yet; and you can't run
>64 bit programs on a machine running a 32 bit OS (at least not
>easily).  So I currently have no way to test 64 bit programs.
>
>>would be interested to have long and pointers encoded in
>>64 bits. Any remarks or suggestions concerning the way
>>to make the porting easier would be great !
>
>According to what I have heard, longs are still supposed
>to be 32 bits.  Pointers will be 64 bits though, and long longs will
>be 64 bits as before.
>
>The calling convention needs to change to properly support the
>64 bit mode of the r4000, but there is as yet no publicly available
>documentation on the new calling convention.  It would be best
>if the 64 bit gcc r4000 port was compatible with the new ABI.
>I will be trying to get a copy of the ABI; I don't know if I will
>be able to.
>
>A lot of the existing DImode stuff in the MIPS backend will need
>to be rewritten to take advantage of the 64 bit registers.

iank@dircon.co.uk (Ian Kemmish)
>Yes.  Algorithmics are working on a 64-bit gcc for VxWorks.
>They promised me I could go and benchmark my PostScript RIP
>on it next month, though it now looks like I won't have much
>time for things like that.... send mail to dom@algor.co.uk

wwc@dxhra1.desy.de (Wolfgang Wander)
>at Desy we will start with this project in about 2 or 3 weeks
>I think. Perhaps we can stay in contact to reduce our effords?

Dominic Sweetman <dom@algor.co.uk> (Algorithmics)
>Yes, Algorithmics are going to do some 64-bit work on the MIPS GCC,
>and we expect to have something working by the end of November
>(including Ian's Postscript interpreter if we can borrow him and/or it
>for a couple of hours!)
>
>A couple of points:
>
>o This year, we only intend to implement the use of real 64-bit
>  opcodes for "long long" integer types.  We and our existing
>  customers have no immediate use for 64-bit address spaces.
>
>  However, much of the compiler work is presumably common.
>
>  Moreover, 64-bit addressing is going to break a lot of programs.
>  And 64-bit addressing will require extensions to object codes,
>  and thus to assemblers, linkers and everything.
>
>o The MIPS architecture does not really have a "64-bit mode"; most
>  instructions are the same, and do the same, for 32-bit and 64-bit
>  operands.
>
>  Although you have to turn on 64-bit addressing to make 64-bit
>  integer operations work in user mode, 64-bit arithmetic is ALWAYS
>  available in kernel mode.
>
>  The main reason for making 64-bit operations illegal in user mode
>  is this.  Standard 32-bit operations affect the high half as well
>  as the low half of registers.  So in order to use 64-bit register
>  values ALL your library subroutines must be recompiled so that they
>  will save and restore all 64 bits of registers when necessary; and
>  ALL assembler subroutines must be recoded for 64-bit saves.
>
>  Of course your interrupt routines etc must be recoded to save
>  and restore 64 bits too.
>
>  This is much worse than it sounds.  For example, MIPS math operations
>  are only IEE754 compliant if backed up by a software emulator package
>  to handle operations whose operands are out of the range supported by
>  the hardware FPA.  This trap emulator is effectively a library, and
>  you will need to recompile it for 64-bit operation or suffer strange
>  and random failures.
>
>o You'll need an assembler, and we will not be working on extensions
>  to GNU gas (though others might).  We have our own MIPS assembler.
>
>o Some changes to the conventions for passing arguments to subroutines
>  are inevitable, and we haven't seen an authoratitive definition yet.
>  We'll follow the lead from SGI, if there is one.
>
>64-bit operation is only practicable for people who have sources for
>every piece of software they use.
>
>We're certainly happy to share the work we do on GCC as soon as we do
>it.  I know of at least one person in the US who is also urgently
>interested, and with your permission I will pass your name on to him
>too.
>
>Algorithmics' support GCC as part of a development toolkit called
>"SDE-MIPS" which includes not only GNU tools (debugger, linker etc)
>but also our assembler, comprehensive libraries, FP emulation, trap
>handlers etc.  SDE can be hosted on most Unix systems and also
>DOS/386.
>
>We will be producing a complete 64-bit version of SDE for November.
>The package is cheap at 1150 pounds for a single-machine license and
>would get you up and running quickly.


Conclusions :-) :

- GCC support for R4000 64 bit is NOT AVAILABLE currently.
- using a 64 bit compiler is useless without a 64 bit OS supporting it !
- there is a need for 64 bit compilers (developping new apps and new systems)
- GCC support for R4000 64 bit integer operations should be available in
  a near future.
- GCC support for R4000 64 bit pointers (address space) may take longer.

  thanks to all who mailed or post on this subject.
  hope this help,

Daniel.

Daniel Veillard : Bull-IMAG Systems Grenoble France
E-mail : Daniel.Veillard@imag.imag.fr