From: clemc@ccc.com (Clem Cole)
Subject: [TUHS] What sparked lint? [Was: Unix stories]
Date: Thu, 5 Jan 2017 16:06:13 -0500 [thread overview]
Message-ID: <CAC20D2NChdi_RUGH+tJa7epG1T4DFsP1rb87zdhSZe=TBv7gkg@mail.gmail.com> (raw)
In-Reply-To: <af8081d6-dd25-db9b-79d3-2f83b48fcad0@mhorton.net>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2146 bytes --]
He is right, it was the IBM Series/1 Port and it was a different school
(Miami of Ohio, I think).
Case was Bill Shannon and Sam Leffler's port to an Interdata.
On Thu, Jan 5, 2017 at 3:55 PM, Mary Ann Horton <mah at mhorton.net> wrote:
> I recall at the Delaware Usenix conference (in 1979?) a professor from
> Case Western gave a talk about his port of UNIX to some Interdata or Data
> General or something. He said that when he booted it up, it said "NUXI".
>
> On 01/05/2017 09:46 AM, Ron Natalie wrote:
>
> I remember being at an early UUG meeting and the group who did the UNIX
> port to the IBM series lamenting that it printed NUXI on boot because of
> byte order issues. Don’t know if it was true, but NUXI became a synonym
> for UNIX byte order issues from then on.
>
>
>
>
>
> The 8/32 indeed has some 370-ish stuff starting from the fact that it
> numbers the bits from the MSB end. Amusingly, it has more minicomputerish
> other features.
>
> One bizarre source of fun is that where as accessing a 16 bit quantity on
> an odd address on the PDP-11 gives you a bus error trap, the Interdata just
> ignores the low order bit and returns you the 16 bit value that you are
> pointing into the middle of. Same things happen on 32-bit access (lower 2
> bits ignored).
>
> For nostalgia, here’s a scan of an old 8/32 programmers manual:
> http://bitsavers.trailing-edge.com/pdf/interdata/32bit/8-32/
> 29-428_8-32_User_May78.pdf
>
>
>
> Byte ordering got worked out when networking came in. I worked on
> IBM’s AIX which was a productization of the UCLA LOCUS kernel. The thing
> was a relatively tightly coupled multiprocessor system that allowed
> seamless execution of different binary types. The machines we were
> working with were the 370 mainframe, the i386 (in the form of IBM PS/2’s),
> and a four processor i860 add in card IBM built called the W4. The
> mainframe having the opposite byte ordering of the others.
>
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/tuhs/attachments/20170105/ee9074a8/attachment-0001.html>
next prev parent reply other threads:[~2017-01-05 21:06 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-05 1:30 Nemo
2017-01-05 1:39 ` Larry McVoy
2017-01-05 3:20 ` Steve Johnson
2017-01-05 17:46 ` Ron Natalie
2017-01-05 20:55 ` Mary Ann Horton
2017-01-05 21:06 ` Clem Cole [this message]
2017-01-05 21:17 ` Chet Ramey
2017-01-05 21:30 ` Clem Cole
2017-01-05 21:42 ` ron minnich
2017-01-05 21:51 ` Ron Natalie
2017-01-05 22:02 ` Chet Ramey
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='CAC20D2NChdi_RUGH+tJa7epG1T4DFsP1rb87zdhSZe=TBv7gkg@mail.gmail.com' \
--to=clemc@ccc.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).