7 Dec
2016
7 Dec
'16
9:12 p.m.
From: Clem Cole
DEC's Custom Special Systems (CSS) group .. build
a simple base/limi
register device, soon after the 11/20 was released.> ... So an early
version of after the original 11/20 port from the PDP-7 had this
however.....
Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
see if anyone had _any_ documentation for this, but so far, nada.
I would look at Warren's First Edition work to
see if there were dregs
of this in that code base
Alas, I'd already had that idea (to try and at least re-create a programming
spec, at least, for the KS11). There do not seem to be any traces there,
perhaps because that code came from a document entitled "Preliminary Release
of Unix Implementation", which argues that it's a very early 'version'
of V0
(the early 'versions' weren't very formal, there was a continuous process
of
change/improvement going on, apparently).
It is also noted that the 45 class system
(45/55/70/44) had "17th"
address bit - i.e. split I/D space. I believe that this is when "magic
numbers" were really introduced so that could be supported.
No, they came in first for 'pure text' (0410):
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V4/nsys/ken/sys1.c
which I would expect arrived to minimize swapping on machines with small
amounts of real memmory.
Support for user split-I/D (411) didn't arrive until Version 6:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V6/usr/sys/ken/sys1.c
although IIRC split I/D in the kernel was supported supported slightly
before it was in user - although V5 didn't:
http://minnie.tuhs.org/cgi-bin/utree.pl?file=V5/usr/sys/conf/mch.s
so it couldn't have been much earlier than V6.
Noel
7 Dec
7 Dec
10 p.m.
New subject: Unix & Memory Management Units (MMU)
I can at least shed some light on at least when the Sun boxes supported it
(which may or may not help narrow down the date)
The initial Sun 1/100 multibus machines did not support virtual memory. I
have one of the last (if not the last) original multibus boards
from Sun with the original PROMs... and it was supported up to Sun OS 0.7.
This OS was based off UniSoft UNIX v7. The 0.7 version was released
in 1982.
In order to support virtual memory systems, there was a board upgrade
required. Anyone who wanted to go to SunOS 1.0 had to get this board
upgrade (which from what I know, was a board swap... not sure if money
traded hands as well... and is one core reason the original boards are
rare). The release of Sun OS 1.0 was in November 1983.
So, Sun OS didn't see this until late '83.
Earl
8 Dec
8 Dec
11:39 a.m.
New subject: Unix & Memory Management Units (MMU)
Earl Baugh <earl.baugh(a)gmail.com> wrote:
I can at least shed some light on at least when the
Sun boxes supported it
(which may or may not help narrow down the date)
The initial Sun 1/100 multibus machines did not support virtual memory. I
have one of the last (if not the last) original multibus boards
from Sun with the original PROMs... and it was supported up to Sun OS 0.7.
This OS was based off UniSoft UNIX v7. The 0.7 version was released
in 1982.
In order to support virtual memory systems, there was a board upgrade
required. Anyone who wanted to go to SunOS 1.0 had to get this board
upgrade (which from what I know, was a board swap... not sure if money
traded hands as well... and is one core reason the original boards are
rare). The release of Sun OS 1.0 was in November 1983.
The oldest Sun I had was a multibus machine with a mc68010.....This was in
January 1985. These machines still had a keyboard that was connected to the
frame buffer to play with the row/col readout lines. See:
/usr/include/sys/kbd.h:#define KB_KLUNK 0x00 /* Micro Switch
103SD32-2 */
which is still in the recent sources ;-)
The problem you describe is not related to virtual memory, but to demanded page
loading as an enhancement to the old swapping method. This demanded page
loading did not work at all with the 68000 and even the Bourne Shell triggered
a bug from this deficit - see below.
BTW: The name of the OS was not SunOS these days. AFAIR, the first time it was
called "SunOS" was christmas 1985 (the 0-series of first boards with mc68020
have been built December 24 1985) and the OS was called SunOS-3.0. I never
understood how Sun managed to get these boards delivered through the customs
to Berlin in December 27 or 30. At that time, I was working for the first
large Sun customer H.Berthold AG and we received these boards.
Before SunOS-3.0, it was called similar to "BSD-4.2 UNIX Sun version foo".
I am not sure what you mean with this NULL ptr dereferences. AFAIR, on SunOS I
never could dereference a NULL pointer but in SVr3 nearly all commands used an
option parser that caused a NULL pointer dereference. On SunOS they dumped
core if you tried to compile and run then.
The printf() on SunOS however printed "(null)" for printf("%s",
NULL);
SVr4 used a SunOS kernel and thus did not allow to dereference NULL pointers.
The user space commands have been from SVr3 and _most_ of them had been fixed
to avoid NULL pointer dereferences.
Today, Solaris comes with a libragy 0@0 that maps a page of nulls to address 0.
Call "LD_PRELOAD=0@= command" in case you have one of these nasty programs
developed on Linux that use to dump core on Solaris ;-)
Back to the Bourne Shell:
The original Bourne Shell did not use malloc, but rather had a SIGSEGV handler
that used to extend the "string stack" called "stak" via sbrk()
whenever the
code tried to access data beyond the end ot the heap.
This method was great, but did not work with the mc68000, as the 68000 had a
conceptional bug in the micro code. It could not restart code like:
*to++ = *from++;
correctly after the return from an exception handler trap.
What Sun did at that time was to add tests to the code to avoid that SIGSEGV
hits. This code is still in recent Bourne Shell versions.
I did however discover a missed place in the code last year while running a
fuzzer on the code. Note that the "stak" module has been replaced 2012 with
code based on a rewrite from Geoff Collyer. See:
http://schilytools.sourceforge.net/bosh.html
Jörg
--
EMail:joerg@schily.net (home) Jörg Schilling D-13353 Berlin
joerg.schilling(a)fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sourceforge.net/projects/schilytools/files/
9:50 a.m.
New subject: Unix & Memory Management Units (MMU)
DEC's
Custom Special Systems (CSS) group .. build a simple base/limi
register device, soon after the 11/20 was released.> ... So an early
version of after the original 11/20 port from the PDP-7 had this
however.....
Oh, right, I'd forgotten about that: the KS-11 - I've previously enquired to
see if anyone had _any_ documentation for this, but so far, nada. (the early 'versions' weren't very
formal, there was a continuous process of
change/improvement going on, apparently).
Can't find the reference now, but it
is my understanding that this remained the case throughout. The outside world had
editions, but inside Bell Labs it was a continuous process.
> I believe that this is when "magic
> numbers" were really introduced so that could be supported.
My
understanding is that the first magic number (0407) was present in the earliest PDP11
versions. Apparently, executables were loaded into memory including the header, and
control jumped to the first word loaded. This first word then contained a "jmp
$+8" to jump over the header. It stayed as a relic until reused to distinguish
between regular and pure text binaries. Here, too, I must admit that I have not
scrutinized the V0 source to find support for this understanding.
Paul
2902
days inactive
2903
days old
3 comments
4 participants
participants (4)
-
Earl Baugh -
jnc＠mercury.lcs.mit.edu -
Paul Ruizendaal -
schily＠schily.net