Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer From: klamer@mi.eltn.utwente.nl (Klamer Schutte -- Universiteit Twente) Newsgroups: comp.sys.acorn Subject: Re: C versus ARM Message-ID: Date: 6 Mar 91 12:03:27 GMT References: <6397.9103011248@olympus.cs.hull.ac.uk> <5538@acorn.co.uk> Sender: news@utrcu1.UUCP Distribution: comp Organization: University of Twente, BSC-El Lines: 50 In <5538@acorn.co.uk> jroach@acorn.co.uk (Jonathan Roach) writes: >In article <6397.9103011248@olympus.cs.hull.ac.uk> rst@cs.hull.ac.uk (Rob Turner) writes: >>As long as all our variables were global (as in [most] machine code), >>and all our functions had no parameters, I find it hard to believe >>that the resulting compiled program would be only half the speed of >>the native ARM program. Surely it would be faster than that. >Here we can now focus on what really makes the difference between assembler >and C - the passing of arguments and results from functions. In Rob's < stuff deleted > >and interface heavily with the OS) the effect is small. End aside). What the >compiler in this particular case gets really hammered on is the necessity of >storing away any of the changed 'registers' in their global locations before >calling any functions, and obtaining the values it needs from these global >locations after the function call. This is an enormous overhead! Also, This is a nice point you make there! Off course, the solution is to use another (read: more efficient) calling sequence. This will involve passing parameters in registers and minimizing the number of registers declared scratch in the calling sequence. >cost, then code in assembler (I have not yet been convinced that the >C:assembler ratio is better (for C) than 1.2:1, which goes up to about 2:1 >if there's a lot of SWI calling to be done (which is very cumbersome when >done from C, but real natural from assembler :-)). If you're not too worried When you want an efficient SWI interface, make those a macro to inline assembly. The changes i suggest mean that another C compiler is needed. But C should run faster compared to assembler than it does now; one of the reason to go to RISC architectures (never mentioned in Acorn docs) is that compilers only use a limited set of instructions, so why implement the rest? Here clearly did go something wrong in the ARM chip / high level language design. Klamer PS And a question for the better-informed: When running on a R160 + ARM3 under RISCiX a sample program without very much floating point did perform only at 10% of a Sun Sparcstation 1+ (rated 15 MIPS). The ARM3 should be better than 1.5 (sun) MIPS, isn't he? Unix overhead is not the answer as the SS1+ did run SunOs 4.1 against berkely 4.3 for the ARM. Where does the difference come from? -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer