rcpieter@wsinfo11.info.win.tue.nl (Tiggr) (02/23/91)
kortink@utrcu1.UUCP (Kortink John) writes: >The point I was trying to make was that it is NOT OPTIONAL junk : you're >stuck with the other bulk if you want a few bits out of a package. If the >compiler or linker can filter it : fine ! Acorn's doesn't do it (yet), and >that's the one we have to work with. Including a library because you use printf causes the grief. The printf function is part of and uses stdio, and stdio simply is a lot of code. Even a `smart' linker (I never knew the Acorn one wasn't) could not solve this problem. But then again, of a non trivial program, most code will be object code, not library code. >My graduation project is all about this actually (well, sideways). The idea >is to produce 'dumb' code from something called an abstract program tree, >called register transfer code, and optimize this using a peephole optimizer. Why bother? GNU CC already does this and a lot of other optimisations (GCC uses the register transfer language as the intermediate `code'). >Point d) is where things get interesting, because it is there that you >realize that it is practically impossible to optimize triples or quadruples >or, generally, n-tuples of instructions, because it requires too much of >that something called 'insight'. That depends on how the RTL code was generated. If it was generated by a compiler front-end, certain language constructs will always produce the same RTL code, which is easy to match and optimise by simple peepholing. >True, that is one of the true virtues of *any* high level programming >language. But that is beside the point. We were discussing speed/size issues. The speed of program development is of much higher economical value than the speed of the resulting code (I didn't say thats! It must have been my oppressed alter ego!). Tiggr
lord@sequoia.cray.com (Steven Lord) (02/25/91)
>>If you write "Hello World" using <stdio.h> then yes, you get lots of junk. >>The point is that it's all OPTIONAL junk, which you asked for, and a smart >>compiler and linker can even cut out most of that. [...] >The point I was trying to make was that it is NOT OPTIONAL junk : you're >stuck with the other bulk if you want a few bits out of a package. If the >compiler or linker can filter it : fine ! Acorn's doesn't do it (yet), and >that's the one we have to work with. This is not a function of the compiler or the linker, it is the way the C library is organised. The library is basically an archive of relocatable object code files, the linker looks through it and pulls in the object files it needs to fulfill all the unresolved references in your code. The problem is that Acorn's library is made up of a smallish number of files each with a lot of functions in them, so you probably are getting stuff you don't need. Splitting the library into more files would have helped, but it might have meant the linker had to be more sophisticated, and would have needed more memory to work with (this is a guess). Acorn's way round this is the shared C library, if you link with the o.stubs file instead of the actual library your binary on disc is a lot smaller, and if you use Acorn's applications the shared C library will get loaded anyway. printf("Hello world\n") is a silly thing to do, printf() is for formatted output and has lots of features you don't need for this example, puts() is for strings (but since Acorn probably have them both in the sme source file you probably get printf anyway :-). Steve Lord
ccplumb@rose.uwaterloo.ca (Colin Plumb) (02/25/91)
lord@sequoia.cray.com (Steven Lord) wrote: >This is not a function of the compiler or the linker, it is the way the C >library is organised. > >The library is basically an archive of >relocatable object code files, the linker looks through it and pulls in the >object files it needs to fulfill all the unresolved references in your code. This is not necessarily true; a more intelligent linker (heck, even the Unix linker can do this) only pulls in the necessary functions and ignores the file boundaries. But still, printf() usually calls an underlying _doprnt() which calls putchar() which calls _flsbuf() and maintains an output buffer... plus, there is start-up code to initialize the buffer. Use write() in Unix, or OS_Write0 on the Archimedes if you want small code. -- -Colin
kers@hplb.hpl.hp.com (Chris Dollin) (02/26/91)
Colin Plumb writes:
...
This [only including in an image the particular units needed, not a whole
object file] is not necessarily true; a more intelligent linker (heck, even
the Unix linker can do this) only pulls in the necessary functions and
ignores the file boundaries.
Generally wrong: most Unix linkers will pull in the whole module (file) if any
of its components are required. [This fact is standard flamewar fodder.]
--
Regards, Kers. | "You're better off not dreaming of the things to come;
Caravan: | Dreams are always ending far too soon."fischer@iesd.auc.dk (Lars P. Fischer) (02/27/91)
>>>>> On 23 Feb 91 13:01:00, rcpieter@wsinfo11.info.win.tue.nl (Tiggr) said:
Tiggr> Including a library because you use printf causes the grief. The
Tiggr> printf function is part of and uses stdio, and stdio simply is a lot of
Tiggr> code. Even a `smart' linker (I never knew the Acorn one wasn't) could
Tiggr> not solve this problem.
There's a simple solution to this kind of problem -- dynamic linking.
The linker only resolves the library references with actually copying
the code. When the program is started, the actual binding is done and
the code is copied into memory, provided it's not already there. This
way, only one copy of stdio, say, exists on disk at a time, and at
maximum one copy exists in memory. Saves disk space and memory.
Of course, dynamic linking requires operating system support. Real
operating systems, like SunOS, SysVr4 and Mach have it. Heck, even
OS/2 have it.
Tiggr> But then again, of a non trivial program, most code will be
Tiggr> object code, not library code.
Not so. A real application might use a library of data structures
(strings, trees, hash tables, ..), a user interface construction
library, a database library, a 3D graphics library, a knowledge base
library, and more. This kind of thing is *not* unusual, especially if
the program is written in an OOPL.
On a typical Unix workstation, dynamic linking will easily save you
100 Mbytes of disk space and 4-8 Mbytes of RAM.
/Lars
--
Lars Fischer, fischer@iesd.auc.dk | Beauty is a French phonetic corruption
CS Dept., Univ. of Aalborg, DENMARK. | - FZccplumb@rose.uwaterloo.ca (Colin Plumb) (02/27/91)
kers@hplb.hpl.hp.com (Chris Dollin) wrote: > >Colin Plumb writes: > > ... > This [only including in an image the particular units needed, not a whole > object file] is not necessarily true; a more intelligent linker (heck, even > the Unix linker can do this) only pulls in the necessary functions and > ignores the file boundaries. > >Generally wrong: most Unix linkers will pull in the whole module (file) if any >of its components are required. [This fact is standard flamewar fodder.] Well, I might be wrong; I'm no expert. I just read the linker man page: ... If any argument is a library, it is searched exactly once at the point it is encountered in the argument list. Only those routines defining an unresolved external reference are loaded. ... (this is pretty vanilla 4.3BSD) and it seemed to describe the desired behaviour. -- -Colin
x51@nikhefh.nikhef.nl (Excursiecommissie) (02/28/91)
In article <807@utrcu1.UUCP> kortink@utrcu1.UUCP (Kortink John) writes: > >>You should also bear in mind that the productivity of C programmers (in >>terms of working object code produced) is about ten times that of assembly >>language programmers. > >True, that is one of the true virtues of *any* high level programming >language. But that is beside the point. We were discussing speed/size issues. > >John Kortink It is a well known fact that a good algorithm in a compiled language can be much faster than a bad algorithm, written in assembly. Now, about the speed issue: If the programmer is using C, he can implement much faster and has time to spare to think of a better algorithm. The assembly man is using so much of his time-resources, that he might not have the time left to think of a better algorithm (Although this is ofcourse different for the elegant ARM code). Conclusions: Think before you type. :-) Axel
rogersh%t5g@uk.ac.man.cs (Huw J. Rogers) (02/28/91)
In article <1786@svin02.info.win.tue.nl> rcpieter@info.win.tue.nl writes: >kortink@utrcu1.UUCP (Kortink John) writes: > >>The point I was trying to make was that it is NOT OPTIONAL junk : you're >>stuck with the other bulk if you want a few bits out of a package. If the >>compiler or linker can filter it : fine ! Acorn's doesn't do it (yet), and >>that's the one we have to work with. The linker isn't the problem - Acorn's libraries are. The granularity is huge. Under UNIX each library function is in a separate object file within the library, solving this problem. Unfortunately Acorn lump masses of s**t into just a few object files. > >Including a library because you use printf causes the grief. The >printf function is part of and uses stdio, and stdio simply is a lot of >code. Even a `smart' linker (I never knew the Acorn one wasn't) could >not solve this problem. Not true - printf() calls doprnt() calls flsbuf() calls write() - just 4 functions. >But then again, of a non trivial program, most >code will be object code, not library code. What does this mean? > >(GCC uses the register transfer language as the intermediate `code'). Could you post details of the RiscIx port of gcc and the RTL->ARM translation, and how you persuade gcc to produce AOF format files? [ H.J.Rogers (INTERNET: rogersh%p4%cs.man.ac.uk@cunyvm.cuny.edu) ] [ ,_, (BITNET/EARN: rogersh%p4%cs.man.ac.uk@UKACRL.BITNET) ] [ :-(_)-o (UUCP: ...!uunet!cunyvm.cuny.edu!cs.man.ac.uk!p4!rogersh) ] [ _} {_ (JANET: rogersh%p4@uk.ac.man.cs) ]
gks@doc.ic.ac.uk (Gary K Smith) (03/01/91)
Well, following this discussion closely, my view on the subject is that C is a lot easier to use than assembly language, but for some time critical operations, it would be better to use ARM. Now to use the two in combination, I assume you need an assembler which will create Object files, and then link them. Is there one around, apart from the ridiculously expensive Acorn one? Is there even a PD one around? If so, would someone please mail it to me? Thanks Gary --