The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: ron@ronnatalie.com (Ronald Natalie)
Subject: [TUHS] speaking of early C compilers
Date: Mon, 27 Oct 2014 11:09:27 -0400	[thread overview]
Message-ID: <25DC9219-F0CD-4456-81A3-CF93EDD7A616@ronnatalie.com> (raw)
In-Reply-To: <20141027144833.536A618C0A5@mercury.lcs.mit.edu>

We thought the kernels got cleaned up a lot by the time we got to the BSD releases.    We were wrong.
When porting our variant of the 4 BSD to the Denelcor HEP supercomputer we found a rather amusing failure.

The HEP was a 64 bit word machine but it had partial words of 16 and 32 bits.   The way it handled these was to encode the word size in the lower bits of the address (since the bottom three weren't used in word addressing anyhow).    If the bottom three were zero, then it was the full word.  If it was 2 or 6, it was the left or right half word, and 1,3, 5, and 7 yielded the four quarter words.  (Byte operations used different instructions so they directly addressed the memory).

Now Mike Muuss who did the C compiler port made sure that all the casts did the right thing.   If you cast "int *" to "short *" it would tweak the low order bits to make things work.    However the BSD kernel in several places did what I call conversion by union:  essentially this:

union carbide {
     char*  c;
     short* s;
     int*     i;
} u;

u.s  = ...some valid short* ...
int* ip = u.i;

Note the compiler has no way of telling that you are storing and retrieving through different union members and hence the low order bits ended up reflecting the wrong word size and this led to some flamboyant failures.     I then spent a week running around the kernel making these void* and fixing up all the access points to properly cast the accesses to it.

The other amusing thing was what to call the data types.     Since this was a word machine, there was a real predisposition to call the 64 bit sized thing "int" but that meant we needed another typename for the 32 bit thing (since we decided to leave short for the 16 bit integer).     I lobbied hard for "medium" but we ended up using int32.   Of course, this is long before the C standards ended up reserving the _ prefix for the implementation.

The afore mentioned fact that all the structure members shared the same namespace in the original implementation is why the practice of using letter prefixes on them (like b_flags and b_next etc... rather than just flags or next) that persisted long after the C compiler got this issue resolved.

Frankly, I really wish they'd have fixed arrays in C to be properly functioning types at the same time they fixed structs to be proper types as well.     Around the time of the typesetter or V7 releases we could assign and return structs but arrays still had the silly "devolve into pointers" behavior that persists unto this day and still causes problems among the newbies.




  reply	other threads:[~2014-10-27 15:09 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-27 14:48 Noel Chiappa
2014-10-27 15:09 ` Ronald Natalie [this message]
2014-10-27 15:13 ` Dave Horsfall
2014-10-27 16:52 ` Dan Cross
  -- strict thread matches above, loose matches on Subject: below --
2014-10-28  1:55 Jason Stevens
2014-10-28 12:52 ` Ronald Natalie
2014-10-27 18:16 Nelson H. F. Beebe
2014-10-27 16:50 Norman Wilson
2014-10-27 15:48 Noel Chiappa
2014-10-27 16:25 ` Dave Horsfall
2014-10-28  0:16   ` John Cowan
2014-10-27 13:54 Jason Stevens
2014-10-27 13:46 Noel Chiappa
2014-10-27 10:32 Jason Stevens
2014-10-27 13:03 ` Brantley Coile
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

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=25DC9219-F0CD-4456-81A3-CF93EDD7A616@ronnatalie.com \
    --to=ron@ronnatalie.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).