faeychild wrote:
My first computer was a DEC PDP-7 (put a cork in it). It had
8k of memory and used a 18 bit word (6 octal). It - had -
lights!!! Under each light was a switch 1 ea for each data
bit and 1 for each address. We had to memorize the basic 16
instructions, ie: 100 100 xxx xxx xxx xxx was ISZ ( izzie )
increment and skip if zero (ie 441034 - add. 1034) 020 000 ...
was LAC, load accumulator, 10 DAC, deposit accumulator.

To write the first program you would set the address switches
to say 000 000 001 000 000 (100) and the AC(cumulator) switches
to 111 111 111 111 101 111 press deposit (up) and the address
would automagicly go to 101 (Oooooooooooooooo) then
you would set the AC switches to 001 001 000 000 000
DAC 1000 and press deposit-next (down) and the address
lights would go to 102. .... flip, flip, flip...... flip deposit
next, flip, flip, flip... deposit next. With practice you could
do a 100 step program without paper, “... lets see, I put
count4 in 1000 and it has a -16 in it, I put the char string
“starting” at 1040,41,42,3,4,5,6,7. Ok, address switches
still at 100, press start! .. (S***) Examine locate 122
... stupid .. its 1040 not 1100 (1 sw off) – set switches,
deposit, reset address = 100, press start. “Will wonders
never cease!” it ran. Then you would load, by hand, another
small program that would send locations 100 to 200 to the
Paper Tape Punch and the machine would spit out 2 feet
of paper tape with holes in it. (ad-100, 101000, ad-101, .....)
so the later you could put the tape in the reader, press Load
and magically all of you hard work was back in the computer.

Then you would go on to (using paper) write a 2000 lines of
code that would convert:
....
LAC -16 (load AC with a minus 16)
DAC ct1 (deposit at the first free memory location
LAC (buf1 (load AC with the address of buf1
DAC pt1 (save pointer
DZM * pt1 (deposit zero in memory indirectly
ISZ pt1 (buf1 + 1
ISZ ct1 (ct1 now = minus 15, -14, -13, -12....
JMP .-3 (jump back 3 locations
.... when ct1 one hit zero the jump -3 would be skipped and
the program flow would continue. So when...

printf (“You write a simple %d line program\n”, LineCt);
printf (“please understand that %7f programmers\n”, BodyCt);
printf (“spent %26d hours developing the micro code that”);
printf (“that is sitting in the CPU chip you using.\n”);

Because the more things change the more they stay the same. :-/

Old grey fart.

faeychild wrote:

--
Gary G. Taylor * Rialto, CA
gary at donavan dot org / http:// geetee dot donavan dot org
"The two most abundant things in the universe
are hydrogen and stupidity." --Harlan Ellison

faeychild wrote:
By writing it in another language.

Now, before you get too chicken/eggish, at some point, you devolve to machine
language toggled into the computer through outside means.

FWIW, the first C compiler was written in PDP 7 assembly language.


--
Lew Pitcher

Master Codewright and JOAT-in-training
Registered Linux User #112576 (http://counter.li.org/)
Slackware - Because I know what I'm doing.

In article <gqdkb.216$x23.7723@news.uswest.net>, Chuck <chuck@liderbug.com> wrote:
The modern computers are so BOOOORIIING... they don't have lights!!! I'm sure
that if someone came up with a PCI card that you could put into your PC and a
front panel filled with lights (LEDs) just flashing, there would be a good
market for it.

Jørn Dahl-Stamnes, EDB Teamco AS
e-mail: Jorn.Dahl-Stamnes@nospam.novit.no (remove nospam first)
web: http://spiderman.novit.no/dahls/

On Sun, 19 Oct 2003 22:51:42 -0400, Lew Pitcher <lpitcher@sympatico.ca> wrote:
A floppy with enough machine code to build an assembler in a minimal
OS and enough assembly code to build the compiler in a more complete OS.
All in a ramdisk.

One floppy. With lots of room left over.

With compiled binaries being at least 50X the size of the sourcecode, let's
say that 3MB of C source (compressed into 1MB) could yield 150MB of Linux
leaving 400KB for the machine and assembly code.

That would be a rather nice Linux installation from a single floppy.....

--
Alan C
Posts with sigs of > 4 lines, or not in plain text, are dumped by my filters.

On Mon, 20 Oct 2003 06:29:06 +0000, Alan Connor wrote:

This is not right - source code is almost always bigger than the resulting
binary. E.g. for the lcd4linux system I'm trying out at the moment, the
uncompiled source directory is 2.2M, whereas the compiled program is 547K
- about 4 times smaller.

andy.

--
remove 'n-u-l-l' to email me. html mail or attachments will go in the spam
bin unless notified with [html] or [attachment] in the subject line.

On Mon, 20 Oct 2003 15:13:03 +0100, Andy Baxter <news3@earthsong.null.free-online.co.uk> wrote:

Odd. I have a whole directory full of smallish C programs, and every one of
them is many times larger than their source.

Try writing a little printf program and check it out.

Perhaps what you have is source code that must deal with a variety of
situations/hardware and so forth.

Like the kernel sources which have the source for 5X as many drivers as
an individual is likely to use.

--
Alan C
Posts with sigs of > 4 lines, or not in plain text, are dumped by my filters.

Lew Pitcher wrote:
and, as you just jogged my memory ...... UNIX was developed on a
PDP-7 - Oh those days, those days, lights, lac's, dac's and now
nothing but one DZM after another ....

On Mon, 20 Oct 2003 18:29:06 +0000, Alan Connor wrote:

I think the most likely reason for this is that these programs are using
statically linked libraries, rather than dynamic ones, so when they are
compiled the compiler pulls in a load of extra binary code from the
relevant libraries. In which case the fair comparison would be with the
source of the program plus all the relevant source from the library.

I don't know enough about how C instructions get translated into machine
code to be certain on this, but it seems to me that compiled code will
generally be shorter than source because all the symbols such as function
and variable names will be translated from long character strings into
shorter numeric references. Also consider comments, which get
translated into precisely nothing... This will depend a bit on how the
programmer labels and comments their code of course.

andy.

--
remove 'n-u-l-l' to email me. html mail or attachments will go in the spam
bin unless notified with [html] or [attachment] in the subject line.

On Tue, 21 Oct 2003 04:42:48 +0100, Andy Baxter <news3@earthsong.null.free-online.co.uk> wrote:

<snip>
I'm using gcc as it came with Debian. Why would it be setup to statically-
link common libraries? They aren't idiots at Debian, you know.....

--
Alan C
Posts with sigs of > 4 lines, or not in plain text, are dumped by my filters.

Alan Connor wrote:

Well if you will insist on answering your own questions ... :-)

--
Ron House house@usq.edu.au
http://www.sci.usq.edu.au/staff/house

On Tue, 21 Oct 2003 15:56:41 +1000, Ron House <house@usq.edu.au> wrote:
Not following you, Ron....

--
Alan C
Sigs belong below the "-- " and are limited to 4 lines.
If your sigs don't conform, I will killfile you for 30 days.

On Mon, 20 Oct 2003 at 18:29 GMT, Alan Connor wrote:
Do that. Then add another line. Compile. Compare sizes. Repeat.

For example:

#include <stdio.h>
int main() {
puts("Hello, world");
return 0;
}

Source: 71; Executable: 15713

#include <stdio.h>
int main() {
puts("Hello, world");
puts("Hello, world");
return 0;
}

Source: 95; Executable: 15729

Diff: Source: 24 bytes; Executable: 16 bytes

The executable contains start-up and exit code which is a fixed
size. As you can see, an additional 24 bytes in source code only
increases the executable by 16 bytes.


--
Chris F.A. Johnson http://cfaj.freeshell.org
================================================== =================
My code (if any) in this post is copyright 2003, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License

Alan Connor wrote:
It's not gcc that'd be setup to statically link your applications. The
makefile for the individual applications may have a "-static" option in
their linker arguments for some reason or another. GCC is just obeying
the programmer's request.

Really, though, I don't think one can give a general answer to the
question of whether the C source or compiled binary is larger. There
are just too many variables to consider. As somebody else pointed out,
source comments compile into nothing so you'd think the binary would be
smaller. OTOH, sometimes a single expression in C will expand to many,
many operations after compilation. Remember that C has a lot of
high-level concepts that machine code doesn't, the result being a dozen
or so instructions to implement a seemingly simple C expression.

Then you can get into static vs. dynamic libraries, what optimizations
were used in compiling the app (in particular, -Os), and so on. Even
the programmer's personal style (short, terse source vs. verbose
comments, long function and variable names, etc.) enters into the
equation.

I honestly don't think there is a general answer to the question of
which is smaller.

On 21 Oct 2003 15:30:49 GMT, Chris F.A. Johnson <c.fa.johnson@rogers.com> wrote:
Clear as a bell. Thanks Chris.

--
Alan C
Chronic Netiquette violators killfiled for 30 days. That includes PGP sigs.

On Tue, 21 Oct 2003 11:35:13 -0400, John-Paul Stewart <jpstewart@sympatico.ca> wrote:

Much appreciated.

Could the same be said for assembly code?

--
Alan C
Chronic Netiquette violators killfiled for 30 days. That includes PGP sigs.

Chris F.A. Johnson wrote:
Also, the executable contains the symbol table, which may be
removed by running the 'strip' program or compiling with the
-s (I think) option. That will shrink the executable
noticeably.

Another point to ponder is that those small 'C' programs
contain startup code and library code which originally were
many lines of source code.

[rest snipped]

Alan Connor wrote:

For x86 assembly language the relation (without comments) is about 4 to 1
That is, source is about 4 times the size as the resulting binary. Always
without comments, because those will be dependent upon the author
--
No trees were destroyed in the sending of this message, however, a
significant number of electrons were terribly inconvenienced.

"Lew Pitcher" <lpitcher@sympatico.ca> wrote in message
news:2jivmb.8oo.ln@merlin.l6s4x6-4.ca...
Been there - done that.

In late 1960's we built a computer in the computer lab of Helsinki
University of Technology (see <http://www.hut.fi/>). When built, the only
software that existed for it was 14 words of bootstrap loader hard-coded (a
diode matrix).

The first task was to toggle in a piece of code that was able to dump
selected areas of core to the paper tape punch in such a format that the
built-in boot was able to load it back. Of course, the first target was the
dumper itself, so we had the first piece of loadable code that did something
sensible.

Second phase was to create a simple octal assembler. It was written in its
own language, hand-translated and toggled in so many times that it was able
to assemble itself.

In third phase a real symbolic assembler was built. Again, it was written in
its own language, translated to the older assembler by hand and iterated
till it was able to handle itself.

Just imagine debugging a couple of hours by single stepping the code and
reading from the bus data and address lamps what was going on - my nostalgy
does not extend to want that back.

The following phases were much easier, as there was a pretty good tool to
get the binary code from. An editor saved from cutting and splicing
(literally) the paper tape, a relocating assembler and linker made libraries
possible etc.

A compiler was also built. The language of choice then was a bastardised
version of Basic, as it was about the only above-assembler language
available then (well before C and Forth & co) which could be squeezed to
compile in a computer with 20 kwords of 24 bits with primitive instructions.
The compiler was written in the relocating assembler, as well as its
run-time libraries.

Tauno Voipio
tauno voipio @ iki fi

On Tue, 21 Oct 2003 at 20:37 GMT, Homer Welch wrote:
The same relationship holds true after stripping. This table shows
the various sizes (with the difference from the previous example).

The first column is the number of times << puts("Hello, world");>>
appears in the source code file :

No. of puts() Source Executable Stripped
1 ( ) 71 ( ) 11,353 ( ) 2,696 ( )
2 ( 1) 96 ( 25) 11,369 ( 16) 2,712 ( 16)
22 ( 20) 596 ( 500) 11,689 ( 320) 3,032 ( 320)
122 (100) 3,096 ( 2,500) 13,289 ( 1,600) 4,632 ( 1,600)
300 (178) 7,546 ( 4,450) 16,137 ( 2,848) 7,480 ( 2,848)
1,255 (955) 31,421 (23,875) 31,417 (15,280) 22,760 (15,280)

At 300 lines, the source code exceeds the size of the stripped
executable, and the non-stripped at 1,255 lines.

--
Chris F.A. Johnson http://cfaj.freeshell.org
================================================== =================
My code (if any) in this post is copyright 2003, Chris F.A. Johnson
and may be copied under the terms of the GNU General Public License