csuwr@warwick.ac.uk (Derek Hunter) (02/13/91)
My penn'orth is this: Currently, I only have BASIC on the Arc, so I am rather limited in what I can use (Until my C compiler is finished. I don't waste money on commercial things... :-). I have written a records system for BASIC (I, II, III, IV & V, takes ~1K I seem to remember) /in/ BASIC, so I'm essentially writing my compiler in a very messy Pascal type thing. (I may post the records library if people want it. Uncoded since it's only ~1K and I don't intend to line Pilling's pocket) On UNIX, I write short, very quick, messy and one-shot things in Pascal since BASIC isn't on it, and it would only be Microsoft anyway. For big things, I much prefer C. (t's why I want a version for the Arc - A handy 3rd year project). Since I have to adapt in my programming from tape Beebs up to UNIX, I have no really strong feelings because I don't usually have a choice, but if I were forced to make a decision, I would say BASIC V comes joint with Pascal (Better if they had inbuilt records, and decent file and string handling respectively), and first ANSI C with a darn intelligent linker, and stdio, math, strings,and malloc built into the compiler as extensions producing inline coding. I do feel that massive 'Hello world' binaries is silly, but then you'll only /ever/ really write /one/ of those, won't you? Anyway any halfway decent compiler should spot the disuse of int main(argc, argv, env) sort of 'extras', and not 'include' them. One question, does the Arc's C compiler have a math.h, and does this make it jump to subroutines, or are the FP codes assembled like any other things? - Derek . . . The man with no .sig (I've seen the problems...) - Derek . . . The man with no .sig (I've seen the problems...) - Derek . . . The man with no .sig (I've seen the problems...) [snigger]
john@acorn.co.uk (John Bowler) (02/14/91)
In article <1991Feb12.233654.5140@warwick.ac.uk> csuwr@warwick.ac.uk (Derek Hunter) writes: >Since I have to adapt in my programming from tape Beebs up to UNIX, I have > no really strong feelings because I don't usually have a choice, but if I > were forced to make a decision, I would say BASIC V comes joint with Pascal > (Better if they had inbuilt records, and decent file and string handling > respectively), and first ANSI C with a darn intelligent linker, and stdio, > math, strings,and malloc built into the compiler as extensions producing > inline coding. With the exception of mathematical operations which correspond to the FP instruction set inlining doesn't seem to help very much on the ARM2 - particularly with stdio and malloc (where the saving of a BL/MOVS PC,LR instruction pair is trivial compared to the overhead in the operations. [Even fgetc needs 11 instructions, including 2 LDR, one STM and one LDM; about 25S cycles (equivalent) compared to 8 for the function call overhead, and it *does* use all the APCS function call registers. The RISC iX malloc has about 20 instructions, 44 S cycles. Both functions are (effectively) hand optimised assembler.] With an ARM3 in-lining is likely to be disadvantageous - code size will increase significantly in some program inner loops and this will descrease overall performance because the in-line code effectively flushes the cache. [It is difficult to arrive at hard figures for this.] String function in-lining has been used by some manufactures to get good dhrystone ratings but the only obvious advantage on the ARM would come from converting strcpy of string constants into memcpy or LDM/STM (depending on string length); even here the small gains hardly seem worth while. Effectively this is just a work-round for the absence of support in C for array assignment. [Note that it has never been particularly clear how best to do structure assignment on the ARM. LDM/STM versus out-of-line calls to versions of memcpy - code size/execution speed questions again; ANSI C release 3 seems to use in-line code at the moment, in the case I tried this cost 4 extra in-line instructions]. Even in-lining DIV and MOD (/ and %) is not done; currently RISC iX uses out-of-line loop unrolled functions, which would be very expensive to in-line. I beleive C/RISCOS_Lib uses the same technique but with less unrolling (on the basis that this is likely to be better on ARM3). > >One question, does the Arc's C compiler have a math.h, and does this make it > jump to subroutines, or are the FP codes assembled like any other things? Math functions are the clear exception; where they correspond to an FP code the compiler can take advantage of not having the APCS floating point caller save registers trashed. Since most FP ops involve only two registers (in practice) this releases two fp registers for use as temporaries. Anyway, all the out-of-line function would do is execute the FP op-code. Unfortunately most ANSI-C math interfaces do *not* correspond to FP op-codes, because they require errno to be set. In-lining the tests of FP status and changes to errno is more difficult, currently the compiler only supports in-lining of sin(), cos(), atan() and fabs() [the out-of-line implementation of the latter, incidentally, can avoid FP operations by doing the operation itself - more efficient even with a hardware coprocessor with the existing APCS]. This in-lining is switched on (if desired) inside math.h. The FORTRAN compiler on the other hand is capable of in-lining far more math functions - FORTRAN programs do not expect errno to be updated! The result is that some mathematical programs may compile to more efficient code when written in FORTRAN. John Bowler (jbowler@acorn.co.uk)