zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) (02/18/91)
Here a question of common interest: Is it possible to port the GNU-C-Compiler to Archimedes running RISC-OS ? I've seen a port of GNU-C-Compiler for Acorn Archimedes running RICSix (unix) in ftp.win.tue.nl by martin simmons (mss10@phoenix.cambridge.ac.uk) and Tiggr (rcpieter@win.tue.nl) What are the difficulties to port this software to RISCOS ? So long J. Scheurich
gtoal@tharr.UUCP (Graham Toal) (02/19/91)
In article <1991Feb18.112436.26820@rusmv1.rus.uni-stuttgart.de> zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) writes:
:Here a question of common interest:
:Is it possible to port the GNU-C-Compiler to Archimedes running RISC-OS ?
:I've seen a port of GNU-C-Compiler for Acorn Archimedes running RICSix (unix)
:in ftp.win.tue.nl by
:martin simmons (mss10@phoenix.cambridge.ac.uk)
:and
:Tiggr (rcpieter@win.tue.nl)
:
:What are the difficulties to port this software to RISCOS ?
:
:So long
:J. Scheurich
Finding someone competant and with time enough to do it.
Are you volunteering? Tiggr will be filing the ARM (unix) diffs with
rms any day now (if not already). I *think* the majority of what
needs to be done for risc os is write a decent assembler; not too
hard a task really.
*many* people claim to have started working on GCC for risc os and
then you never hear of them again... :-(
Graham
--
(* Posted from tharr.uucp - Public Access Unix - +44 (234) 261804 *)zzassgl@uts.mcc.ac.uk (Geoff Lane) (02/19/91)
On a similar subject - has anyone modified the GNU assembler to accept ARM opcodes? I had a look a couple of months ago and it seemed like it would require a lot of work - more than I could justify for the little amount of assembler I needed. (It would be nice if it were possible to make the Basic assembler generate something that the linker would accept ;-)) -- Geoff. Lane. Janet: zzassgl@uk.ac.mcc.cms UTS Sys Admin, Manchester Computing Centre, Oxford Rd, Manchester, M13 9PL
osmith@acorn.co.uk (Owen Smith) (02/20/91)
In article <1991Feb18.112436.26820@rusmv1.rus.uni-stuttgart.de> zrzm0111@helpdesk.rus.uni-stuttgart.de (MUFTI) writes: >Is it possible to port the GNU-C-Compiler to Archimedes running RISC-OS ? Interesting tit-bit of info I picked up at my previous company while working on 88000 workstations. Norcroft C for the 88000 produces code about 10 to 15 percent slower than GNU C for the 88000. Some of this was due to GNU C being better at moving instructions around to take advantage of the parallelism in the 88K, and on the ARM it will lose this edge. But this only accounted for about half of the difference, the other half was GNU C being just plain better at performing various optimisations. Note that the 88K version of Norcroft C has diverged somewhat from the Acorn version. I don't know which of the Acorn version or the 88K Norcroft version produces faster code, but I'd place reasonable odds on the 88K version. Thus a GNU C for the Archimedes stands a fair chance of producing a worthwhile speed increase in compiled C programs. Of course, if GNU C cannot be made to make use of conditional instructions, then the potential speed increase is reduced but is probably still worthwhile. Owen. The views expressed are my own and are not necessarily those of Acorn.
acn@cl.cam.ac.uk (Arthur Norman) (02/20/91)
Owen Smith makes some observations about the speed of code generated
by the Norcroft compiler on an 88000 compared with GCC, and makes
deductions about what one could expect on the ARM. It may be useful to
note that (a) the 88000 compiler is in a very early pre-release state
(pending sorting out the 88000 most exciting va_args convention!) and I
would expect to speed it up before release, (b) in particular it hardly
had any treatment of instructi0n scheduling, which on the 88000 is fairly
vital but which does not have any relevance on the ARM, (c) the ARM version
of ncc has a fairly large chunk of machine specific tuning and optimisation
that again the 88000 one mentioned did not. Thus I do NOT believe one can
generalise and expect gcc/ARM to produce significantly better code than
ncc over a wide range of styles and quantities of code. But I do hope
that if people can spot ways in which ncc could be persuaded to produce
5% smaller or 5% faster code ACROSS LARGE BODIES OF REALISTIC CODE and not
just in one tiny case they will forward the ideas into Acorn/ARM Ltd.
We have just about got ncc going on a mips machine, to the state where I
have only one time measurement, and at present I am uncertain of its
reliability, but that suggests that ncc is winning relative to gcc wrt
speed of compiled code and in this very first working version is only 1.5%
behind on code density - we will fix that up soon. Furthermore on the
particular releasze of gcc involved the prohgram I most want to run
misbehaves (just slightly) when -O is specified, so until I have chased
that down & found a fixed gcc I am not really going to be able to quote
timings.
Cheers Owen!
Arthur Normanrcpieter@wsinti02.info.win.tue.nl (Tiggr) (02/20/91)
osmith@acorn.co.uk (Owen Smith) writes: >Thus a GNU >C for the Archimedes stands a fair chance of producing a worthwhile speed >increase in compiled C programs. Of course, if GNU C cannot be made to make >use of conditional instructions, then the potential speed increase is >reduced but is probably still worthwhile. GNU CC as it currently runs on my box emits conditional instructions. Produced code is 20% larger and 20% slower than /bin/cc produced code (numbers may vary -20%+80%). (These numbers will get better when I start hacking again.) Also, GNU CC takes quite a lot more time and memory and /bin/cc. I don't expect it ever to run comfortably on a 2Meg RISCOS machine. Tiggr
osmith@acorn.co.uk (Owen Smith) (02/21/91)
In article <1991Feb20.085225.11667@cl.cam.ac.uk> acn@cl.cam.ac.uk (Arthur Norman) writes: >Thus I do NOT believe one can >generalise and expect gcc/ARM to produce significantly better code than >ncc over a wide range of styles and quantities of code. Well maybe things aren't as hopeful as I'd thought. But on the other hand it is always helpful to have two completely different compilers for your machine to help in the classic "is it a bug in the compiler or in my program?" quandries. gcc for the ARM might never approach the speed, code size and reliability of Norcroft on the ARM, but gcc does have one other distinctive feature. It is free. And in my humble opinion, a free C compiler for the Archimedes would be a good thing. Hopefully it would encourage more people to try C out. I suspect a lot of people use BASIC and Assembler simply because it is free with the machine and generally adequate. Given an alternative without spalshing out lots of dosh might get them interested. They may then find they like C, but the gcc port is too buggy/the code is too slow/big or whatever, and save up and buy Norcroft. Cheers Arthur! Owen. The views expressed are my own and are not necessarily those of Acorn.
johny@syma.sussex.ac.uk (Lord Yak Da Hairy) (02/21/91)
I'm not so sure about gcc, but I would like to see g++ and gdb on the Archimedes. Particularly gdb, as I hate asd (is it just me setting it up completely wrongly, or am I stuck with debugging at assembler-level rather that source-level? Yuch.) A port of GNU emacs would be nice, too. I might do this myself, but I'll need more HD space first, as I currently have 600K free and the emacs source distribution takes about 10Mb... -- John Yeates (Lord Yak Da Hairy) -------------------------------------------- -- johny@syma.sussex.ac.uk OR johny@cogs.sussex.ac.uk (0273) 678318 -- Always be excellent, never be rude, with the GIFT OF GAB from DR DUDE! And if we're lucky, the binaries group might be up by the time I've finished...
fischer@iesd.auc.dk (Lars P. Fischer) (02/27/91)
>>>>> On 21 Feb 91 12:22:43 GMT, osmith@acorn.co.uk (Owen Smith) said:
Owen> gcc for the ARM might never approach the speed, code size and
Owen> reliability of Norcroft on the ARM,
On all the architectures I have used, GCC has been very close to other
available compilers, or better. GCC version 1.xx have a number of
problems with generating efficient code for some RISC architectures
due to some unfortunate design decisions and the lack of facilities
such as instruction scheduling. This is being addressed in version
2.xx, currently in alpha test. Still, version 1.xx generates as good
code as the Sun C compiler on a SPARC.
As to reliability, GCC has been more reliable than the system compiler
and other commercial compilers for most machines I have used. It is
interesting to note that the release note for each version of GCC
includes the statement "This release fixes all previously reported
bugs".
The only problem I can see with GCC for the ARM is the memory usage of
GCC. A compiler that use 4 Mbytes (or more) when optimizing might not
be a favorite with home computer users.
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | Beauty is a French phonetic corruption
CS Dept., Univ. of Aalborg, DENMARK. | - FZosmith@acorn.co.uk (Owen Smith) (03/01/91)
In article <FISCHER.91Feb26191821@thiele.iesd.auc.dk> fischer@iesd.auc.dk (Lars P. Fischer) writes: >GCC version 1.xx have a number of >problems with generating efficient code for some RISC architectures >due to some unfortunate design decisions and the lack of facilities >such as instruction scheduling. The Data General 88K version of GNU C 1.37 seemed to do a pretty decent job of instruction scheduling when I was using it. Did Data General do more than just write an 88K back-end or what? And anyway, will any of these new features for 2.xx help the ARM? The ARM has no appreciable instruction scheduling type features. PS. I know about the 4 word boundaries or whatever it is, but this gains you little and the optimisation needs to be different for an ARM 2 and an ARM 3 anyway, making it virtually useless unless you take the decision that the ARM 3 is fast enough without doing this optimisation and so you always position instructions for the ARM 2. But this is positioning not scheduling - can GCC 2.xx handle this? Owen. The views expressed are my own and are not necessarily those of Acorn.
stevec@wren.inmos.co.uk (Steve Clarke) (03/04/91)
In article <5486@acorn.co.uk> osmith@acorn.co.uk (Owen Smith) writes: >The Data General 88K version of GNU C 1.37 seemed to do a pretty decent >job of instruction scheduling when I was using it. Did Data General >do more than just write an 88K back-end or what? On some RISC compilers, the instruction scheduling is actually performed by the assembler. On some GCC implementations, the manufacturer's assembler is used, as this speeds up porting (plus it can be hard to port gas to some assembler syntaxes). Gcc 1.37 doesn't do any instruction scheduling; so could it be that the version of GNU C that you were using passed the assembly language on to the manufacturer's assembler (which then did the instruction scheduling) rather than using the GNU assembler? >Owen. --- Stephen Clarke INMOS Ltd, Bristol | EMail(UK) ukc!inmos!stevec The opinions above are my personal | or stevec@inmos.co.uk views and do not reflect INMOS policy. | Internet: stevec@inmos.com
osmith@acorn.co.uk (Owen Smith) (03/05/91)
In article <14624@ganymede.inmos.co.uk> stevec@wren.inmos.co.uk (Steve Clarke) writes: >Gcc 1.37 doesn't do any instruction scheduling; so >could it be that the version of GNU C that you were >using passed the assembly language on to the manufacturer's assembler >(which then did the instruction scheduling) rather than using the GNU >assembler? The compiler was not using the GNU assembler (not quite sure which one it was using - either Motorola or Data General probably). But this is irrelevant, as I was doing gcc -S and looking at the assembler source. I assure you it was doing instruction scheduling - it took me AGES to find my divide instruction once - it had been moved unbelievably far back, so far in fact that it had completed by the time the results were used! A divide in one cycle! Amazing! This was not the only example. There were lots of other minor adjustments it was doing for multiple cycle instructions. The assembler cannot do as good a job of scheduling, because the registers have been fixed by then. The compiler has the option to jiggle the register colouring to get a register free for ages for the benefit of long instructions (basically multiply, divide and floating point on the 88K). This still doesn't answer my original question - will gcc 2.xx have any new features which will actually be beneficial for an ARM version? Owen. The views expressed are my own and are not necessarily those of Acorn.