The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: brantley@coraid.com (Brantley Coile)
Subject: [TUHS] speaking of early C compilers
Date: Mon, 27 Oct 2014 13:03:15 +0000	[thread overview]
Message-ID: <255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com> (raw)
In-Reply-To: <0F0B9BFC06289346B88512B91E55670D2F86@EXCHANGE>

Early C allowed you to use the '->' operator with any scaler.  See early C reference manuals.  This is the reason there is one operator to access a member of a structure using a pointer and another, '.', to access a member in a static structure.  The B language had no types, everything was a word, and dmr evolved C from B.  At first it made sense to use the '->' operator to mean add a constant to whatever is on the left and use as an l-value.  

You will also find that member names share a single name space.   The simple symbol table had an bit in each entry to delineate members from normal variables.  You could only use the same member name in two different structs if the members had the same offsets.  In other words, it was legal to add a member name to the symbol table that was already there if the value of the symbol was the same as the existing entry. 

Dennis' compilers kept some backward compatibility even after the language evolved away from them. 

This really shows the value of evolving software instead of thinking one has all the answers going into development.  If one follows the development of C one sees the insights learned as they went.  The study of these early Unix systems have a great deal to teach that will be valuable in the post Moore's law age.  Much of the worlds software will need to a re-evolution. 

By the way, did you notice the compiler overwrites itself?   We used to have to work in tiny spaces.  Four megabytes was four million dollars. 

Sent from my iPad

> On Oct 27, 2014, at 6:42 AM, Jason Stevens <jsteve at superglobalmegacorp.com> wrote:
> 
> has anyone ever tried to compile any of the old C compilers with a 'modern'
> C compiler?
> 
> I tried a few from the 80's (Microsoft/Borland) and there is a bunch of
> weird stuff where integers suddenly become structs, structures reference
> fields that aren't in that struct,   
> 
> c01.c
>        register int t1;
> ....
>                t1->type = UNSIGN;
> 
> 
> And my favorite which is closing a bunch of file handles for the heck of it,
> and redirecting stdin/out/err from within the program instead of just
> opening the file and using fread/fwrite.. 
> 
> c00.c
>    if (freopen(argv[2], "w", stdout)==NULL ||
> (sbufp=fopen(argv[3],"w"))==NULL)
> 
> 
> How did any of this compile?  How did this stuff run without clobbering
> each-other?
> 
> I don't know why but I started to look at this stuff with some half hearted
> attempt at getting Apout running on Windows.  Naturally there is no fork, so
> when a child process dies, the whole thing crashes out.  I guess I could
> simulate a fork with threads and containing all the cpu variables to a
> structure for each thread, but that sounds like a lot of work for a limited
> audience.
> 
> But there really is some weird stuff in v7's c compiler.
> _______________________________________________
> TUHS mailing list
> TUHS at minnie.tuhs.org
> https://minnie.tuhs.org/mailman/listinfo/tuhs



  reply	other threads:[~2014-10-27 13:03 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27 10:32 Jason Stevens
2014-10-27 13:03 ` Brantley Coile [this message]
2014-10-27 13:34   ` Ronald Natalie
2014-10-27 13:40     ` random832
2014-10-27 14:04       ` Clem Cole
2014-10-27 15:04       ` Dave Horsfall
2014-10-27 17:09 ` scj
2014-10-27 20:35   ` Ronald Natalie
2014-10-27 21:34     ` Clem Cole
2014-10-28  1:09       ` Dave Horsfall
2014-10-28  2:06         ` Clem Cole
2014-10-28 12:22           ` Ronald Natalie
2014-10-28 12:42             ` Clem Cole
2014-10-28 13:03               ` Ronald Natalie
2014-10-28 22:02                 ` John Cowan
2014-10-27 13:46 Noel Chiappa
2014-10-27 13:54 Jason Stevens
2014-10-27 14:48 Noel Chiappa
2014-10-27 15:09 ` Ronald Natalie
2014-10-27 15:13 ` Dave Horsfall
2014-10-27 16:52 ` Dan Cross
2014-10-27 15:48 Noel Chiappa
2014-10-27 16:25 ` Dave Horsfall
2014-10-28  0:16   ` John Cowan
2014-10-27 16:50 Norman Wilson
2014-10-27 18:16 Nelson H. F. Beebe
2014-10-28  1:55 Jason Stevens
2014-10-28 12:52 ` Ronald Natalie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=255EF9E2-2BA3-4928-8664-7C7B08FB48D4@coraid.com \
    --to=brantley@coraid.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).