dave@cs.arizona.edu (Dave P. Schaumann) (01/21/91)
In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: >I was looking through some programs that were written in C, and I noticed that >a few were really SMALL! Like only 2k for a full-blown clock. How does the >program get so small! It seems that if I compile a program like > >#include <stdio.h> >main(){printf("hey man!\n");} The reason even a minimal C program, ie "main(){}" compiles to ~4K is that it you have to link it to the run-time library. This has code for stuff like parsing the command line, and setting up stdin/stdout. If you had something like "main(){real x; x = 0.0;}", it would be even larger, because now you would be bringing in all the f.p. routines as well. >the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile >smaller then a printf statement. > >[...] > >Can 'C' code get small? I have a LIST program in the works. It's 14000 >bytes compared to c:list's 2500. Assembly must be the only decent way to >go. As you guessed, if you want *really* small code, you have to use assembler. Then you only have the code you need to run your program, and no extra hidden stuff. As an aside, I would like to point out that unless you're writing something that is extremely time critical, or *every* *byte* *counts*, writing a whole program in assembly is probably overkill. Masochists & obsessives are, of course, exempt. Real time simulations are a good example if the former, and utilities that are permenantly resident (like a system clock) or used frequently are good examples of the latter. > "These are not ASUN's, DN's, or Phil Dietz > the Regent's opinions. Therefore 231b3678@fergvax.unl.edu > they aren't full of 'filler.'" Univ. of Nebraska Python disclaimer: "It was one of Wilde's!" Dave Schaumann | And then -- what then? Then, future... dave@cs.arizona.edu | -Weather Report
estdwha@warwick.ac.uk (CrisP) (01/21/91)
In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: >I was looking through some programs that were written in C, and I noticed that >a few were really SMALL! Like only 2k for a full-blown clock. How does the >program get so small! It seems that if I compile a program like > >#include <stdio.h> >main(){printf("hey man!\n");} > >the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile >smaller then a printf statement. Have you tried writing printf()? printf is not a simple statement. It is for formated output. The string you give it is not the string to be written but the format of the string to be written. The code to do the formatting is not small. puts() is what you should replace all printf()'s with only one argument with. > >What are steps to compile the smallest Lattice code? Here are the few that I >know. > >1) Use protos and include files whenever possible. Using protos and includes is just good programming practice. It won't reduce the size of your code. >2) Utilize .library calls when possible and don't forget to OPEN it so > the pragmas dont go to waste. >3) Try not to use printf and any amiga.lib function for the matter. Actualy amiga.lib contains both the c.lib functions and stubs for the system library call suct as Open() in the DOS library. >4) Compile with -Lvrt -curfist -rr -mat -O -b1 file to create registerized > code. The only other thing is that you can use _main() inseted of main(). This get rid of all the startup waffle needed for the c libaray routines. such as read, write, malloc, free and anything that uses them. Note that the workbench startup waffle also accurs in _main(). The DOS and Exec libraries are Open'd before _main(). > >Can 'C' code get small? I have a LIST program in the works. It's 14000 >bytes compared to c:list's 2500. Assembly must be the only decent way to >go. > >Phil Dietz Yes thay can. Try _main() { Write(Output(), "hay man!\n", 9L); } ~CrisP. -- ----------------------------------------------- crisp@uk.ac.warwick.cs estdwha@uk.ac.warwick.cu
vinsci@nic.funet.fi (Leonard Norrgard) (01/21/91)
In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes:
#include <stdio.h>
main(){printf("hey man!\n");}
the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile
smaller then a printf statement.
If it was a printf *statement* maybe then it would be smaller. Now
however, it is a call to a library routine that depends on C stdio,
which is usually large. Basically your single call to printf drags in
lots and lots of code to handle all kinds of things.
Try this:
main(){Write(Output(),"Hey man!\n",9);}
The result should be much smaller. However, since you do not use stdio
in the program (Write() is not stdio) you can use the lattice
_tinymain instead. See the library manual, page L264 for usage.
Phil Dietz
-- Leonarddavid@starsoft (Dave Lowrey) (01/21/91)
In article <702@caslon.cs.arizona.edu>, Dave P. Schaumann writes: > In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: > >I was looking through some programs that were written in C, and I noticed that > >a few were really SMALL! Like only 2k for a full-blown clock. How does the > >program get so small! It seems that if I compile a program like > > > >#include <stdio.h> > >main(){printf("hey man!\n");} > > The reason even a minimal C program, ie "main(){}" compiles to ~4K is that it > you have to link it to the run-time library. This has code for stuff like > parsing the command line, and setting up stdin/stdout. If you had something > like "main(){real x; x = 0.0;}", it would be even larger, because now you > would be bringing in all the f.p. routines as well. > > >the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile > >smaller then a printf statement. > > > >[...] > > > >Can 'C' code get small? I have a LIST program in the works. It's 14000 > >bytes compared to c:list's 2500. Assembly must be the only decent way to > >go. > > As you guessed, if you want *really* small code, you have to use assembler. > Then you only have the code you need to run your program, and no extra hidden > stuff. > True, but there IS a way to get smaller C code. You have to write your own startup code. Most compilers supply the code for their startup routine (SAS calls theirs c.c). You can copy it and modify it to take out the extra stuff. ---------------------------------------------------------------------------- These words be mine. The company doesn't care, because I am the company! :-) Dave Lowrey | david@starsoft or {uhnix1,lobster}!starsoft!david Starbound Software Group | Houston, TX | "Dare to be stupid!" -- Weird Al Yankovic
bj@cbmvax.commodore.com (Brian Jackson) (01/22/91)
In article <188e595a.ARN262e@starsoft> david@starsoft writes: >In article <702@caslon.cs.arizona.edu>, Dave P. Schaumann writes: > >> In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: >> >I was looking through some programs that were written in C, and I noticed that >> >a few were really SMALL! Like only 2k for a full-blown clock. How does the >> >program get so small! It seems that if I compile a program like >> > >> >#include <stdio.h> >> >main(){printf("hey man!\n");} [...] >> >Can 'C' code get small? I have a LIST program in the works. It's 14000 >> >bytes compared to c:list's 2500. Assembly must be the only decent way to >> >go. >> >> As you guessed, if you want *really* small code, you have to use assembler. >> Then you only have the code you need to run your program, and no extra hidden >> stuff. >> >True, but there IS a way to get smaller C code. > >You have to write your own startup code. Most compilers supply the code >for their startup routine (SAS calls theirs c.c). You can copy it and >modify it to take out the extra stuff. The "Hey Man" code can be made real small in C. (I used Manx 5.0 for this but I assure you all that this is not a "slam" on SAS :) ) : extern struct DOSBase *DOSBase ; _main() { if(DOSBase = (struct DOSBase *)OpenLibrary("dos.library", 0L )) { Write(Output(), "hey man!\n", 9L ) ; CloseLibrary( DOSBase ) ; } } This compiles and links to just 392 bytes. So you can get C code pretty small. Most C compilers asume a "worst case scenario" and include a lot of extraneous stuff. Each compiler differs in the way it does this so the ways needed to circumvent the problem differ as well. The above code totally blows off the startup and exit code and goes directly to AmigaDOS (Hence the need to open DOS Library myself.) This is about as close to doing it in assembler as C gets. bj ----------------------------------------------------------------------- | Brian Jackson Software Engineer, Commodore-Amiga Inc. GEnie: B.J. | | bj@cbmvax.cbm.commodore.com or ...{uunet|rutgers}!cbmvax!bj | | "Homer, I couldn't help overhear you warping Bart's mind." | ----------------------------------------------------------------------- > Dave Lowrey | david@starsoft or {uhnix1,lobster}!starsoft!david
cctr120@csc.canterbury.ac.nz (Brendon Wyber, C.S.C.) (01/22/91)
In article <10571.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > The next step is to drop the c.o altogether (I think Chuck... argh, > can't remember the last name, mentioned this a while back), so you > open whatever libraries you want (don't need Exec, but you may need > AmigaDOS), etc, and link without c.o. > Unfortunately OpenLibrary is an Exec Function thus you do need it. It must be in initialised to the value of ExecLibrary Pointer (which I believe is kept in memory location 4). Does any one have a working example of this? Be seeing you, Brendon Wyber Computer Services Centre, b.wyber@csc.canterbury.ac.nz University of Canterbury, New Zealand. "Ph-nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn."
jbickers@templar.actrix.gen.nz (John Bickers) (01/22/91)
Quoted from <1991Jan20.210328.18087@hoss.unl.edu> by 231b3678@fergvax.unl.edu (CS 231 section 2): > What are steps to compile the smallest Lattice code? Here are the few that I > know. Some more I've come across, mostly from a document John Toebes (sp?) wrote once... > 1) Use protos and include files whenever possible. If you don't need to your command line parsed, call your main() function _main(), or add this line to your BLINK WITH file: DEFINE __main=_main Otherwise, add this line to your BLINK WITH file: DEFINE __main=__tinymain In both cases use the XCEXIT() function in place of exit() throughout your program, and compile with -v for stack checking off. If you don't use the malloc() functions, and don't use floating point, you can also add this one: DEFINE _MemCleanup=___fpinit You also want to use the SC, SD, and ND options with blink. > Can 'C' code get small? I have a LIST program in the works. It's 14000 > bytes compared to c:list's 2500. Assembly must be the only decent way to Once you've done the above, a hello world sort of program has the bulk of its code in the c.o module you link with. #include <exec/types.h> #include <libraries/dos.h> #include <proto/dos.h> void _main() { Write(Output(),"Hello World\n",12); } The next step is to drop the c.o altogether (I think Chuck... argh, can't remember the last name, mentioned this a while back), so you open whatever libraries you want (don't need Exec, but you may need AmigaDOS), etc, and link without c.o. #include <exec/types.h> #include <libraries/dos.h> #include <proto/dos.h> #include <proto/exec.h> struct Library *DOSBase; void foo() { DOSBase = OpenLibrary("dos.library",0L); Write(Output(),"Hello World\n",12); CloseLibrary(DOSBase); } This, or variations on this... > Phil Dietz -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
andy@cbmvax.commodore.com (Andy Finkel) (01/22/91)
In article <702@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: >>I was looking through some programs that were written in C, and I noticed that >>a few were really SMALL! Like only 2k for a full-blown clock. How does the >>program get so small! It seems that if I compile a program like >> >>#include <stdio.h> >>main(){printf("hey man!\n");} > >The reason even a minimal C program, ie "main(){}" compiles to ~4K is that it >you have to link it to the run-time library. This has code for stuff like >parsing the command line, and setting up stdin/stdout. If you had something >like "main(){real x; x = 0.0;}", it would be even larger, because now you >would be bringing in all the f.p. routines as well. >>Can 'C' code get small? I have a LIST program in the works. It's 14000 >>bytes compared to c:list's 2500. Assembly must be the only decent way to >>go. > >As you guessed, if you want *really* small code, you have to use assembler. >Then you only have the code you need to run your program, and no extra hidden >stuff. > Well, actually, the 2.0 commands in the C: directory are written in C, not assembler. The reason we can get so small is: 1) we compile without a startup. For a small command, often the startup is a major part of the program itself. Because these commands get called in a CLI environment, we can make certain assumptions, and do without a startup. 2) We use 2.0 AmigaDOS calls (ReadArgs() ) to parse the command line andy -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "God was able to create the world in only seven days because there was no installed base to consider." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
markv@kuhub.cc.ukans.edu (01/23/91)
> the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile > smaller then a printf statement. Assembler has a lot to do with it. A C compiler pulls in a lot of code for run time support. > What are steps to compile the smallest Lattice code? Here are the few that I > know. > > 1) Use protos and include files whenever possible. > 2) Utilize .library calls when possible and don't forget to OPEN it so > the pragmas dont go to waste. > 3) Try not to use printf and any amiga.lib function for the matter. > 4) Compile with -Lvrt -curfist -rr -mat -O -b1 file to create registerized > code. Well, you can cheat quite a bit. Write all your I/O to use Amiga system lib funcs. Rewrite the startup to be bare bones and not pull in things. Play with the preprocessor. I have a file "mystdio.h" that I include after stdio.h that includes things like: #define puts(s) {Write(Output(), s, strlen(s));} This gets pretty efficient assuming an inline strlen. Things like sprintf(), fprintf(), etc (w/o fancy formatting) can be emulated using RawDoFmt() and Write(). Fopen can be done with things like: #define "w" MODE_NEWFILE #define "r" MODE_OLDFILE #define fopen(f, m); Open(f, m); Note that doing things like this you loose the support you get from the normal C library like buffering, auto file closing, etc. Modes like "w+", etc require more work but are possible. > Can 'C' code get small? I have a LIST program in the works. It's 14000 > bytes compared to c:list's 2500. Assembly must be the only decent way to > go. See how small it gets if you use AmigaDOS functions like Examine(), ExNext(), Write()) and system support, RawDoFmt(), etc instead of C lib functions like printf(), dnext(), etc. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Mark Gooderum Only... \ Good Cheer !!! Academic Computing Services /// \___________________________ University of Kansas /// /| __ _ Bix: markgood \\\ /// /__| |\/| | | _ /_\ makes it Bitnet: MARKV@UKANVAX \/\/ / | | | | |__| / \ possible... Internet: markv@kuhub.cc.ukans.edu ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
jbickers@templar.actrix.gen.nz (John Bickers) (01/23/91)
Quoted from <1991Jan22.095620.10209@csc.canterbury.ac.nz> by cctr120@csc.canterbury.ac.nz (Brendon Wyber, C.S.C.): > In article <10571.tnews@templar.actrix.gen.nz>, jbickers@templar.actrix.gen.nz (John Bickers) writes: > > open whatever libraries you want (don't need Exec, but you may need > > AmigaDOS), etc, and link without c.o. > Unfortunately OpenLibrary is an Exec Function thus you do need it. It must be > in initialised to the value of ExecLibrary Pointer (which I believe is kept in > memory location 4). Does any one have a working example of this? Lattice is smart enough to know that it can get ExecBase straight out of $00000004. No explicit ExecBase variable is required. The following is the OMDed result of one of these small Hello World programs... _foo 0000-00 _DOSBase 0000-01 SECTION 00 "small.c" 00000054 BYTES | 0000 48E7 3000 MOVEM.L D2-D3,-(A7) | 0004 43FA 0034 LEA 0034(PC),A1 | 0008 7000 MOVEQ #00,D0 | 000A 2C78 0004 MOVEA.L 0004,A6 | 000E 4EAE FDD8 JSR FDD8(A6) ... The line at 000A is loading ExecBase into A6, and the next line is calling the OpenLibrary routine. Presumably the #pragma syscall (as opposed to #pragma libcall) in the <proto/exec.h> file is what does this trick. > Brendon Wyber Computer Services Centre, -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
hclausen@adspdk.UUCP (Henrik Clausen) (01/23/91)
In article <1991Jan20.210328.18087@hoss.unl.edu>, CS 231 section 2 writes: > I was looking through some programs that were written in C, and I noticed that > a few were really SMALL! Like only 2k for a full-blown clock. Hmm, I did such a beast quite recently. Used the _main() routine for entry point. > #include <stdio.h> > main(){printf("hey man!\n");} > > the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile > smaller then a printf statement. printf() is a VERY general output statement that knows about floats, doubles, hex, decimal, chars and various sizes of arguments. Also using the main() entry point in itself is quite costly, doing WB stuff, argument parsing, opening stdio, malloc() stuff and more. > What are steps to compile the smallest Lattice code? > > 1) Use protos and include files whenever possible. > 2) Utilize .library calls when possible and don't forget to OPEN it so > the pragmas dont go to waste. > 3) Try not to use printf and any amiga.lib function for the matter. > 4) Compile with -Lvrt -curfist -rr -mat -O -b1 file to create registerized > code. 5) Use as little startup code as possible. > Can 'C' code get small? How about 88 bytes? Yes, C can get small indeed. Try using tinymain, or call your entrance point _main(), or even skip the startup code completely. printf() drags in most of stdio and makes for several K of code. And look at the c.o module, it's added to your program as well. The following example compiles into 88 bytes of code! No global variables, no main(), no DOSBase ready, no argument parsing, no WB awareness. Note the blink line - there is nothing added to the object file during linking! Use under 2.0 only, it will enable the '*' character for wildcard in the Shell. Thanks to Doug Walker for the neat tricks, including it's self-making ability! ; /* ;EXECUTE THIS FILE AS A SHELL SCRIPT AND IT WILL COMPILE ITSELF lc -cwus -O -v -j73 Star blink from Star.o to Star SmallData SmallCode quit */ #include <exec/types.h> #include <dos/dosextens.h> #include <proto/exec.h> #include <proto/dos.h> void star(void) { struct DosLibrary *DOSBase; struct RootNode *Root; if (DOSBase = (struct DOSBase *)OpenLibrary("dos.library", 36)) { Root = DOSBase->dl_Root; Root->rn_Flags |= 1 << 24; CloseLibrary((struct Library *)DOSBase); } } And here's the executable for documentation - much shorter than the source! begin 777 Star M #\P ! - #Z0 TO#D/Z "1P)"QX 1.X KKOW82H!G$") (&D (@CH -$ZN_F(L7TYU9&]S+FQI8G)A<GD #\@1.X X end This should bring your smallest programs much down in size. I've seen a 'Hello, world' program at 124 bytes using similar tricks using Write() and Output(). Nothing dirty about it, but you will have to do the stuff you usually let the startup code take care of. You might also want to customize the startup code, the source is included in the SAS/C distribution. Happy hacking -Henrik ______________________________________________________________________________ | Henrik Clausen, Graffiti Data | If the Doors of Perception where cleansed, | | ...{pyramid|rutgers}!cbmvax! | Man would see Reality as it is - Infinite. | \______cbmehq!adspdk!hclausen___|_________________________________W. Blake___/
wasp@chumly.ka.sub.org (Walter Mildenberger) (01/25/91)
In article <VINSCI.91Jan21023935@nic.nic.funet.fi>, Leonard Norrgard writes: |In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: program A : | #include <stdio.h> | main(){printf("hey man!\n");} | | the result is 4424 bytes, OPTIMIZED and all. How can a HUGE clock compile | smaller then a printf statement. | [...] |Try this: program B: | | main(){Write(Output(),"Hey man!\n",9);} | |The result should be much smaller. However, since you do not use stdio |in the program (Write() is not stdio) you can use the lattice |_tinymain instead. See the library manual, page L264 for usage. Well, this is right, but create an icon and attach it to the programs, then start the programs from Workbench: while program A works right, b will cause a guru : NOW you know why using "normal" C , not counting on the last byte ;-) Regards -- Walter Mildenberger, Morgenstr. 55, W-7500 Karlsruhe 1, FRG SubNet: wasp@chumly.ka.sub.org ****** Voice: +49 721 385090 * Disclaimer: nobody cares 'bout what I say, so what ?!? **
Jay@deepthot.UUCP (Jay Denebeim) (01/27/91)
In article <1991Jan21.012040.25817@warwick.ac.uk> estdwha@warwick.ac.uk (CrisP) writes: >In article <1991Jan20.210328.18087@hoss.unl.edu> 231b3678@fergvax.unl.edu (CS 231 section 2) writes: >>Can 'C' code get small? I have a LIST program in the works. It's 14000 >>bytes compared to c:list's 2500. Assembly must be the only decent way to The C: LIST from DOS 2.0 is pure C code. No assembly whatsoever. Here's the size: ---p-rwed 90-12-21 01:34:00 9 4464 List >>Phil Dietz > >~CrisP. >-- > >----------------------------------------------- >crisp@uk.ac.warwick.cs estdwha@uk.ac.warwick.cu -- |_o_o|\\ |. o.| || The Jay Denebeim | . | || Software | o | || Distillery | |// Address: mcnc!wolves!deepthot ====== BBS:(919)-460-7430 VOICE:(919)-460-6934
UH2@psuvm.psu.edu (Lee Sailer) (02/12/91)
Let me summarize... If you write plain vanilla C programs, like the ones you were taught as an undergrad, you'll get programs with two characteristics. 1) They will be portable to nearly any other C supporting environment, and 2) they will be big. To write *small* C programs for the Amiga, you have to write them with the Amiga in mind.
J56QC@CUNYVM.BITNET (02/12/91)
To write small programs YOU write THEM in ASSEMBLER :)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/14/91)
In article <91042.134209J56QC@CUNYVM.BITNET> J56QC@CUNYVM.BITNET writes:
To write small programs YOU write THEM in ASSEMBLER :)
No, _you_ write them in assembler. _I_ write them in the best language
for the job.
Example: I just spent 30 seconds turning out a "hello world" program
in a language chosen to 1) be portable, and 2) generate small
executables. The executable is 20 bytes long. How small is your best
assembler effort?
<mike
--
Look at my hopes, Mike Meyer
Look at my dreams. mwm@pa.dec.com
The currency we've spent, decwrl!mwm
I love you. You pay my rent.GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) (02/14/91)
In article <MWM.91Feb14030520@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) says: > >In article <91042.134209J56QC@CUNYVM.BITNET> J56QC@CUNYVM.BITNET writes: > To write small programs YOU write THEM in ASSEMBLER :) > >No, _you_ write them in assembler. _I_ write them in the best language >for the job. You're right here... > >Example: I just spent 30 seconds turning out a "hello world" program >in a language chosen to 1) be portable, and 2) generate small >executables. The executable is 20 bytes long. How small is your best But this is VERY hard to believe.. 'hello world' is 11 bytes, how on earth are you gonna make an executable that's only 9 bytes longer ?????? > <mike ------------------------------------------------------------------------ Ives Aerts | IBM definition SY-34378 GUTEST8@BLEKUL11.BITNET | A signature consists of sequences of gutest8@cc1.kuleuven.ac.be | non-blank characters separated by blanks. ------------------------------------------------------------------------
J56QC@CUNYVM.BITNET (02/14/91)
Sorry guys.. but ASSEMBLER IS STILL THE BEST IF YOU WANT SMALL AND VERY FAST CO E! :) (Flame ON !)
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/15/91)
In article <91045.150604GUTEST8@cc1.kuleuven.ac.be> Ives Aerts <GUTEST8@cc1.kuleuven.ac.be> writes: >Example: I just spent 30 seconds turning out a "hello world" program >in a language chosen to 1) be portable, and 2) generate small >executables. The executable is 20 bytes long. How small is your best But this is VERY hard to believe.. 'hello world' is 11 bytes, how on earth are you gonna make an executable that's only 9 bytes longer ?????? Actually, it's 13 bytes after you add punctuation and the trailing newline. I could probably trim one byte from the executable, leaving it at an extra 6 bytes. And you do it by choosing the right language. This results in a 20 byte file that prints the string "Hello world!" and a newline after I invoke it. <mike -- The handbrake penetrates your thigh. Mike Meyer A tear of petrol is in your eye. mwm@pa.dec.com Quick, let's make love before we die. decwrl!mwm On warm leatherette.
peter@cbmvax.commodore.com (Peter Cherna) (02/15/91)
In article <91045.150604GUTEST8@cc1.kuleuven.ac.be> GUTEST8@cc1.kuleuven.ac.be (Ives Aerts) writes: >But this is VERY hard to believe.. 'hello world' is 11 bytes, how >on earth are you gonna make an executable that's only 9 bytes >longer ?????? Easy, if I guess Mike's idea right: test.rexx: /**/say"Hello World" (Note there is no linefeed at the end) Then, to execute it, type 'rx test.rexx' > Ives Aerts | IBM definition SY-34378 Peter -- Peter Cherna, Software Engineer, Commodore-Amiga, Inc. {uunet|rutgers}!cbmvax!peter peter@cbmvax.commodore.com My opinions do not necessarily represent the opinions of my employer. "Oh, PIN-compatible! I thought you wanted me to make it IN-compatible!"
djohnson@beowulf.ucsd.edu (Darin Johnson) (02/15/91)
In article <MWM.91Feb14030520@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >Example: I just spent 30 seconds turning out a "hello world" program >in a language chosen to 1) be portable, and 2) generate small >executables. The executable is 20 bytes long. How small is your best >assembler effort? Ooooo, you FORTH people can be so smug... (well, how many bytes in BASIC? 16?) -- Darin Johnson djohnson@ucsd.edu - Political correctness is Turing undecidable.
walrus@wor.umd.edu (Udo K Schuermann) (02/15/91)
In article <MWM.91Feb14101400@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >In article <91045.150604GUTEST8@cc1.kuleuven.ac.be> Ives Aerts <GUTEST8@cc1.kuleuven.ac.be> writes: > > >Example: I just spent 30 seconds turning out a "hello world" program > >in a language chosen to 1) be portable, and 2) generate small > >executables. The executable is 20 bytes long. How small is your best > > But this is VERY hard to believe.. 'hello world' is 11 bytes, how > on earth are you gonna make an executable that's only 9 bytes > longer ?????? > >And you do it by choosing the right language. This results in a 20 >byte file that prints the string "Hello world!" and a newline after I >invoke it. > > <mike Excellent, Mike!! The RIGHT language can make a big difference, as I've just found out myself. It's a lesson for us all! ___ ._. Udo Schuermann / | \ "There is no Way to Peace. ( ) walrus@wam.umd.edu \/|\/ Peace is the Way!" -- Gandhi. ~~~
cedman@golem.ps.uci.edu (Carl Edman) (02/15/91)
In article <MWM.91Feb14101400@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: In article <91045.150604GUTEST8@cc1.kuleuven.ac.be> Ives Aerts <GUTEST8@cc1.kuleuven.ac.be> writes: >Example: I just spent 30 seconds turning out a "hello world" program >in a language chosen to 1) be portable, and 2) generate small >executables. The executable is 20 bytes long. How small is your best But this is VERY hard to believe.. 'hello world' is 11 bytes, how on earth are you gonna make an executable that's only 9 bytes longer ?????? Actually, it's 13 bytes after you add punctuation and the trailing newline. I could probably trim one byte from the executable, leaving it at an extra 6 bytes. And you do it by choosing the right language. This results in a 20 byte file that prints the string "Hello world!" and a newline after I invoke it. I'm afraid he means that he used BASIC to write it. In BASIC such a save-file length is perfectly possible (if keywords like 'print' are tokenized). I'm also afraid that he disqualifies himself as what he produced is not an executable. Its execution requires a long interpreter which will make it grow beyond the size needed by any other language. I wont even go into all the other horrible ills of BASIC. Carl Edman "We hold that what one man cannot morally do, a million men cannot morally do, and government, representing many millions of men, cannot do." -- Auberon Herbert Send mail to Carl Edman <cedman@golem.ps.uci.edu>
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/15/91)
In article <865@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: |I'm afraid he means that he used BASIC to write it. [...] No, but I thought about it. Is this true? It is very dishonest to claim the size of a (uncompiled) BASIC program is just the size of the file holding the program. It is really the size of the program + the size of the interpreter. I disagree. It depends on whether or not you have to reload the interpreter every time you run the program. If that's required, then you're right - you should count the interpreter. If the interpreter gets loaded once, the first time you run it, and is always available after that (unless flushed to free memory), then you're wrong - you've got what amounts to a shared library. Cases where one person always has a "library" loaded, and a second person never uses it (i.e. arp.library or cando.library) are ambiguous. I noticed that the original poster neglected to mention which language he used, rather deliberately to my reading of it. Yup. I wanted to see what fell out of that flat - and at first glance impossible - statement. In article <865@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: echo "hello world" is a program in AmigaShell which is roughly 20 bytes long. Bingo. Just add the punctuation, and that's my executable. Note that it meets the portability constraint - that same executable will run on any Unix system, starting with v6, and on any hardware. As for the 'interpreter' argument - echo is built in to the WShell, and execute is either resident, or in the 2.0 ROM (forgot which). So either no extra code is loaded, or execute gets put in ROM and stays there until the space is needed, behaving exactly like a disk library. Why reinvent the wheel ? Which is my point. The nice selection of tools means you can choose something other than C or asm. Given any problem, it can pay to check to see if some other language will work better than C or asm. This could mean you don't spend time rebuilding the things that language provides. With the problem being "produce a small executable", I found that interpreted languages that don't require loading the interpreter work real well. This is especially true on the Amiga, where the interpreter absorbs the required startup overhead (opening libraries) that can be avoided on other systems. As another example, I want to walk a file of bix downloads, and allow the user to skip all messages in a topic that are from a thread tagged as "skip" by the user, where each message has a "I am a reply to ###" on it. This is probably impossible in the shell; and painfull in C or asm (how would you do it?). In ARexx, it requires 1 line at the start of a topic, a 1-line test, 1 line to tag the start of the skipped thread, and 1 line for each message skipped. It was nearly trivial. <mike -- Teddies good friend has his two o'clock feast Mike Meyer And he's making Teddies ex girl friend come mwm@pa.dec.com They mistook Teddies good trust decwrl!mwm Just for proof that Teddy was dumb.
espie@flamingo.Stanford.EDU (Marc Espie) (02/15/91)
echo "hello world"
is a program in AmigaShell which is roughly 20 bytes long.
Even though it's slow, it is often much easier to write a shell-script
than a C program. Depends on the application. With 2.0 enhancements,
the shell becomes much more easier to use, and one of the best ways
to do some simple things (like sorting list output, finding files,
applying the same command to some files recursively, extending
the move commands, and so on).
On the other hand,
/**/
say hello world
is the ``hello world'' program in Arexx. It's roughly 20 bytes long,
and raisonnably fast. Of course, the Arexx interpreter takes around
40 to 60K to work, but it is standard in 2.0, and there's a good chance
you will have the interpreter loaded and running anyway.
Then, you have all the ease of use of a well-conceived programming
language. For many cases, this is an alternative to getting out your
C compiler, especially if the size of the program/effective time
to acheive a one-shot task are the factors.
BASIC ? Yes, it is possible to write short programs in Basic too.
Boy, that would be slow, and the interpreter is *huge*.
Also, I never liked basic, and microsoft's was so brain-dead it didn't
even make it to 2.0, so anyway...
Why reinvent the wheel ? There is a powerful shell at your disposal, there's
Arexx, you don't HAVE to use C for everything !!
And I didn't even speak of Scheme, Maple or other languages. The Amiga
has a plethora of them. So... use your Amiga, guys !
--
Marc Espie (espie@flamingo.stanford.edu)dave@cs.arizona.edu (Dave P. Schaumann) (02/15/91)
In article <CEDMAN.91Feb14124408@lynx.ps.uci.edu> cedman@golem.ps.uci.edu (Carl Edman) writes: |In article <MWM.91Feb14101400@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: | In article <91045.150604GUTEST8@cc1.kuleuven.ac.be> Ives Aerts <GUTEST8@cc1.kuleuven.ac.be> writes: | |Example: I just spent 30 seconds turning out a "hello world" program | |in a language chosen to 1) be portable, and 2) generate small | |executables. The executable is 20 bytes long. How small is your best | But this is VERY hard to believe.. [...] I'll second that. | And you do it by choosing the right language. [...] |I'm afraid he means that he used BASIC to write it. [...] Is this true? It is very dishonest to claim the size of a (uncompiled) BASIC program is just the size of the file holding the program. It is really the size of the program + the size of the interpreter. I noticed that the original poster neglected to mention which language he used, rather deliberately to my reading of it. If it's BASIC, he's busted big time. If it's not, I think he owes us all the name of the language, and specific implementation details (ie, version, vendor, optimizer switches, etc.). -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
dave@cs.arizona.edu (Dave P. Schaumann) (02/15/91)
In article <1991Feb14.214417.13133@Neon.Stanford.EDU> espie@flamingo.Stanford.EDU (Marc Espie) writes: >echo "hello world" > >is a program in AmigaShell which is roughly 20 bytes long. Plus the size of the code to run scripts, plus the size of c:echo >On the other hand, >/**/ >say hello world > >is the ``hello world'' program in Arexx. It's roughly 20 bytes long, Plus the size of Arexx. >BASIC ? Yes, it is possible to write short programs in Basic too. >Boy, that would be slow, and the interpreter is *huge*. Yes!!! This is the point! If you don't include the size of the interpreter with the size of your program, you are not saying the whole truth. Otherwise, I could say "I've got a 1-byte <insert your favorite application here>". Just write an interpreter to read your 1-byte file, and then (if your byte is the right value, of course) call your applicaton. Agreed, this is an extreme example, but I made it to point out the fact that if you measure the size of an interpreted program only by the size of the input to the interpreter, you can have a meaningless result. >Why reinvent the wheel ? There is a powerful shell at your disposal, there's >Arexx, you don't HAVE to use C for everything !! This isn't about language choice. It's about what it takes to do the job. Your example of 'echo "hello world"' is useless to someone without the necessary support code. > Marc Espie (espie@flamingo.stanford.edu) -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
rjc@geech.ai.mit.edu (Ray Cromwell) (02/15/91)
In article <16689@sdcc6.ucsd.edu> djohnson@beowulf.ucsd.edu (Darin Johnson) writes: >In article <MWM.91Feb14030520@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: >>Example: I just spent 30 seconds turning out a "hello world" program >>in a language chosen to 1) be portable, and 2) generate small >>executables. The executable is 20 bytes long. How small is your best >>assembler effort? > >Ooooo, you FORTH people can be so smug... Forth programs need an interpreter. Even using assembly, a 20 byte hello world is impossible. The smallest program I know of is 'Lab', 'EndIf' etc in C: These programs (ARP) are nothing more then a NOP and RTS. However when the hunks are added to the file it becomes 40 bytes long. An assembly hello_world would look like jsr Output(a6) move.l d0,d1 move.l hello,d2 moveq.b #13,d3 jsr Write(a6) rts hello dc.b "hello world",0 This code + hunks would be larger than 40 bytes atleast. (note, its possible to make this code smaller, and jump directly into rom. No sane programmer would do that unless he was brainwashed by the writers of the abacus books. I also left out the code to get DosBase into a6, since I forgot the trick optimization to fetch it from ExecBase.) > >(well, how many bytes in BASIC? 16?) >-- >Darin Johnson >djohnson@ucsd.edu > - Political correctness is Turing undecidable.
cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (02/15/91)
No! Mike is not talking about BASIC... :-) I know of what he speaks, but I'm not going to spoil the fun... :-) Hint: the smallest do nothing `executable' (As you all are thinking about it on the Amiga) is 40 bytes long! This is one RTS instruction. Most of the bytes come from the overhead needed to support the Amiga's dynamic loader, etc... Since Mike claims (I have `checked', he's right of course) his small Hello World is only 20 bytes, he is not talking about a 'C', OR 'asm' program. hehehe Loren J. Rittle -- ``NewTek stated that the Toaster *would not* be made to directly support the Mac, at this point Sculley stormed out of the booth...'' -A scene at the recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so worried about one little Amiga Device... Loren J. Rittle l-rittle@uiuc.edu
cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (02/15/91)
> echo "hello world"
Hey! did you really have to spoil the fun so fast... :-)
There were thousands of people out there guess trying to
guess what Mike was talking about. Boo, party pooper...
Loren J. Rittle
--
``NewTek stated that the Toaster *would not* be made to directly support the
Mac, at this point Sculley stormed out of the booth...'' -A scene at the
recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so
worried about one little Amiga Device... Loren J. Rittle l-rittle@uiuc.edudave@cs.arizona.edu (Dave P. Schaumann) (02/15/91)
In article <MWM.91Feb14150649@raven.pa.dec.com> mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: |In article <865@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: | |I'm afraid he means that he used BASIC to write it. [...] | |No, but I thought about it. | | Is this true? It is very dishonest to claim the size of a (uncompiled) | BASIC program is just the size of the file holding the program. It is | really the size of the program + the size of the interpreter. | |I disagree. It depends on whether or not you have to reload the |interpreter every time you run the program. If that's required, then |you're right - you should count the interpreter. If the interpreter |gets loaded once, the first time you run it, and is always available |after that (unless flushed to free memory), then you're wrong - you've |got what amounts to a shared library. [...] Even if a single copy of the interpreter can be used to execute multiple programs, you still have to count it at least once. Even if you say "resident c:echo", your "echo hello world" still requires the code for echo, even though it is resident, and used for other things. Really, to be strictly accurate, you should include all the AmigaOS support code in your code size, too. The characters "echo hello world" aren't some magic incantation your Amiga instinctively knows what to do with. It takes some kind of shell, which will call c:echo, c:echo, which in turn calls Intuition code. A truely fair measure of how large "echo hello world" is would take into account *all* of the code executed to bring those characters to your screen. If you wanted to get pedantic, you could include the memory required to hold the font used, as well. |[...] |In article <865@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: | | echo "hello world" | | is a program in AmigaShell which is roughly 20 bytes long. Please be careful with author attributations. I did not write this. |Teddies good friend has his two o'clock feast Mike Meyer -- Dave Schaumann | DANGER: Access holes may tear easily. Use of the access | holes for lifting or carrying may result in damage to the dave@cs.arizona.edu | carton and subsequent injury to the user.
cedman@golem.ps.uci.edu (Carl Edman) (02/15/91)
In article <MWM.91Feb14030520@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <91042.134209J56QC@CUNYVM.BITNET> J56QC@CUNYVM.BITNET writes: > To write small programs YOU write THEM in ASSEMBLER :) > > No, _you_ write them in assembler. _I_ write them in the best language > for the job. > > Example: I just spent 30 seconds turning out a "hello world" program > in a language chosen to 1) be portable, and 2) generate small > executables. The executable is 20 bytes long. How small is your best > assembler effort? > > <mike I agree with most things that mike said, but I object to a few things, too: 1. Such a file is _not_ an executable. An executable is machine-code. To call it that is misleading. This is a script/batch/whatever file but _not_ an executable. Please don't reply : "But you can execute them. These other things are not executables. Ever tried 'execute C:ed' ?". Calling these files executables makes about as much sense as calling them binaries as - after all - they consist out of binary digits. 2. Unless I am completely mistaken the original poster asked why some programs for which he received _executables_ were so small. This is an interesting questions and there are quite a few tricks for this. Using basic or smalltalk or rexx is a notoriously bad way to do this. Carl Edman "We hold that what one man cannot morally do, a million men cannot morally do, and government, representing many millions of men, cannot do." -- Auberon Herbert Send mail to Carl Edman <cedman@golem.ps.uci.edu>
cs326ag@ux1.cso.uiuc.edu (Loren J. Rittle) (02/15/91)
> 2. Unless I am completely mistaken the original poster asked why some > programs for which he received _executables_ were so small. This is an > interesting questions and there are quite a few tricks for this. Using > basic or smalltalk or rexx is a notoriously bad way to do this. Humm, last time *I* checked, using ARexx was a notoriously good way to make a small fast _executable_ (in some cases)... An ARexx program to be interpreted is as executable as a compiled C program. If you disagree, go read up on basic CS theory. Anyways, back to why ARexx is a good choice for small fast _executable_: "do i = 1 to 1000; say 'Hello World' i;end" >ram:xx takes 01.683 seconds on my GVP '030 system... while the C program compiled with `lc -O -L test.c' void main(void) { int x; for (x = 1; x < 1001; x++) printf("Hello World %d\n", x); } test >ram:yy takes 00.966 seconds. Humm, considering the fact that both produce the same output, and one took a lot less time to develop and test, I think ARexx is quite a fine choice... When sending the output to the screen, the difference in run times is much harder to find, C 46.5 seconds, ARexx 47.0 seconds! As a bonus, ARexx programs don't (in general :-) crash the machine like C programs can be known to (while testing of course...) on the Amiga. File size: C source 89 bytes, C executable 6536 bytes (sure, I could get it down to 1000-2000, but that would just take more time...) Arexx, 42 bytes Think before you spout off next time! Loren J. Rittle -- ``NewTek stated that the Toaster *would not* be made to directly support the Mac, at this point Sculley stormed out of the booth...'' -A scene at the recent MacExpo. Gee, you wouldn't think that an Apple Exec would be so worried about one little Amiga Device... Loren J. Rittle l-rittle@uiuc.edu
BAXTER_A@wehi.dn.mu.oz (02/15/91)
In article <MWM.91Feb14030520@raven.pa.dec.com>, mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) writes: > In article <91042.134209J56QC@CUNYVM.BITNET> J56QC@CUNYVM.BITNET writes: > To write small programs YOU write THEM in ASSEMBLER :) > > No, _you_ write them in assembler. _I_ write them in the best language > for the job. > > Example: I just spent 30 seconds turning out a "hello world" program > in a language chosen to 1) be portable, and 2) generate small > executables. The executable is 20 bytes long. How small is your best > assembler effort? > > <mike He he. For those not in the know, mike is an utter utter bastard. Here is his program: echo "Hello world" Regards Alan
riley@batcomputer.tn.cornell.edu (Daniel S. Riley) (02/15/91)
In article <869@caslon.cs.arizona.edu> dave@cs.arizona.edu (Dave P. Schaumann) writes: >Really, to be strictly accurate, you should include all the AmigaOS support >code in your code size, too. The characters "echo hello world" aren't some >magic incantation your Amiga instinctively knows what to do with. It takes >some kind of shell, which will call c:echo, c:echo, which in turn calls >Intuition code. A truely fair measure of how large "echo hello world" is would >take into account *all* of the code executed to bring those characters to your >screen. If you do this, you have to do it consistently. That means you have to count the DOS, Console, Intuition, Graphics and Exec code used by the 10 line assembly program that opens DOS and jumps to _LVOWrite. Pretty soon, this gets pretty ridiculous. If you want to exclude ROM routines, I'll want to exclude libraries that I already have loaded and open, and we're back to Mike's position. Regardless of all the flames, I think there are two valid points Mike's example makes--that "Hello world" is not the definitive test for the utility of a language, and that assembly isn't the ultimate language for every job. -Dan Riley (riley@theory.tn.cornell.edu, cornell!batcomputer!riley) -Wilson Lab, Cornell University
mwm@pa.dec.com (Mike (My Watch Has Windows) Meyer) (02/15/91)
In article <1991Feb15.134020.21911@batcomputer.tn.cornell.edu> riley@batcomputer.tn.cornell.edu (Daniel S. Riley) writes:
Regardless of all the flames, I think there are two valid points Mike's
example makes--that "Hello world" is not the definitive test for the
utility of a language, and that assembly isn't the ultimate language
for every job.
Gee, this is getting interesting.
Anyway, the small example makes the difference obvious. But assuming
you've got all your libraries & i/o streams open already, how much
code does it take to print a string in assembler? Someone _mailed_ me
z80 assembler that did my 20 byte example in 21 bytes. I don't think
you're going to do a lot better with a 68000. That's been my
experience elsewhere - the two are about the same size, but one is a
lot easier to write.
And scripts are usefull for more than trivial things. Two examples:
The Lattice/SAS install script does some pretty non-trivial
operations. Yes, it takes forever. But most of that is because you're
copying lots of stuff off of floppies and munging on it after it's on
the hard disk.
I once wrote a fish disk index system as a CLI script. It wasn't very
fast, but like the SAS scripts, most of it was spent doing disk I/O,
or in the sort command. After I got a pipe: device, I made it
multitask by changing "ram:name" to "pipe:name" and "running" a few
commands. That cut the time it took by an order of magnitude. Making
that last change would have been non-trivial in assembler, and might
never have been made. In that case, the "slow" cli script would have
been faster than the "fast" assembler program - and taken much less
time to develop.
<mike
--
Tried to amend my carnivorous habits Mike Meyer
Made it nearly seventy days mwm@pa.dec.com
Loosing weight without speed decwrl!mwm
Eatin' sunflower seedsrwm@atronx.OCUnix.On.Ca (Russell McOrmond) (02/17/91)
In a message posted on 14 Feb 91 22:56:38 GMT,
dave@cs.arizona.edu (Dave P. Schaumann) wrote:
DPS>>is the ``hello world'' program in Arexx. It's roughly 20 bytes long,
DPS>
DPS>Plus the size of Arexx.
And any 'C' example needs the O.S. as well, so we can all dis-agree until
we are blue ;-)
The standard Startup Code on the Amiga is always larger than 20 bytes itself.
Myself, I now consider Arexx to be PART of the O.S., and will be releasing
code this summer that will rely heavily on this O.S. resource (IE: Even in
a 'C' program I will use the REXX libraries to deal with strings for me. The
garbage Collector/etc is Great!)
Why this summer and not now? Because a majority of the people using the
software I write aren't running on an A3000, and aren't registered developers.
DPS>--
DPS>Dave Schaumann | DANGER: Access holes may tear easily. Use of the access
DPS> | holes for lifting or carrying may result in damage to the
DPS>dave@cs.arizona.edu | carton and subsequent injury to the user.
---
Opinions expressed in this message are my Own. I represent nobody else.
Russell McOrmond rwm@Atronx.OCUnix.On.Ca {tigris,alzabo,...}!atronx!rwm
FidoNet 1:163/109 Net Support: (613) 230-2282
Amiga-Fidonet Support 1:1/109 Gateway for .Amiga.OCUnix.On.Cadueker@xenon.arc.nasa.gov (The Code Slinger) (02/19/91)
jbickers@templar.actrix.gen.nz (John Bickers) writes... > > Regardless of the pedantic aspects of all this, the only reasonable > solution to the problem of what to guage program size by is the size > of the file that gets executed. > > The user can then watch out for themselves with respect to what other > overhead may be involved. > To this I wholeheartedly agree. However (adding my $.02): I claim that the term "executed" does not apply to ascii text, ie, shell scripts, etc, because that kind of "code" is more correctly interpreted (whatever I mean by that). It should apply to the "machine code" on whichever machine (read: computer) is involved in the discussion. Chris ------------------------------------------------------------------------ "Ah, Benson, you are so mercifully free of the ravages of intellegence!" "Oh, thank you, Master!" - from the movie, TIME BANDITS ------------------------------------------------------------------------ dueker@xenon.arc.nasa.gov | Chris Dueker (The Code Slinger) duke@well.sf.ca.us | Mtn. View, CA (Sillycon Valley!)
peterk@cbmger.UUCP (Peter Kittel GERMANY) (02/19/91)
In article <60883.666824904@atronx.OCUnix.On.Ca> rwm@atronx.OCUnix.On.Ca (Russell McOrmond) writes: > > Myself, I now consider Arexx to be PART of the O.S., and will be releasing >code this summer that will rely heavily on this O.S. resource (IE: Even in >a 'C' program I will use the REXX libraries to deal with strings for me. The >garbage Collector/etc is Great!) PLEASE tell me more about that! Perhaps you didn't notice, but I posted a question just about this topic (string handling in C) recently in this newsgroup. -- Best regards, Dr. Peter Kittel // E-Mail to \\ Only my personal opinions... Commodore Frankfurt, Germany \X/ {uunet|pyramid|rutgers}!cbmvax!cbmger!peterk
jbickers@templar.actrix.gen.nz (John Bickers) (02/19/91)
Quoted from <869@caslon.cs.arizona.edu> by dave@cs.arizona.edu (Dave P. Schaumann): > Really, to be strictly accurate, you should include all the AmigaOS support > code in your code size, too. The characters "echo hello world" aren't some Note that a C program to do the same thing includes: - The code for AmigaDOS, because of Write() and Output(). - The code for graphics.library, because of the text and layers stuff required. - The code for the CON: device. - The code for the Shell used to load the program. Etc. Regardless of the pedantic aspects of all this, the only reasonable solution to the problem of what to guage program size by is the size of the file that gets executed. The user can then watch out for themselves with respect to what other overhead may be involved. > Dave Schaumann | DANGER: Access holes may tear easily. Use of the access -- *** John Bickers, TAP, NZAmigaUG. jbickers@templar.actrix.gen.nz *** *** "Patterns multiplying, re-direct our view" - Devo. ***
charles@teslab.lab.OZ (Charles Widepy) (02/28/91)
In article <11295.tnews@templar.actrix.gen.nz> jbickers@templar.actrix.gen.nz (John Bickers) writes: > Regardless of the pedantic aspects of all this, the only reasonable > solution to the problem of what to guage program size by is the size > of the file that gets executed. I think that any reasonable person who has even considered this will conclude that there is NO solution to the problem of how to gauge program size. (eg. A program could be written as a very small executable and a large shareable .library.) This is all just an incredibly long winded and pointless discussion, wasting lots of time and money, sparked by someone just trying to prove what a smart arse he is. And lots of followups by people trying to do the same (including this one :). I say we give it a rest. -- / \ CWW charles@teslab.lab.oz.au \_.--._/ ..!uunet!munnari!teslab.lab.oz!charles