From clemc at ccc.com Thu Jan 9 02:02:41 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 8 Jan 2020 11:02:41 -0500
Subject: [COFF] [TUHS -> moving to COFF] # and the Preprocessor
Message-ID: <CAC20D2Pd+gEu8AmsAjJ5vxT+GGfU8PyRXRD7Aux0v2-VUN0N8A@mail.gmail.com>
below... -- warning veering a little from pure UNIX history, but trying to
clarify what I can and then moving to COFF for follow up.
On Wed, Jan 8, 2020 at 12:23 AM Brian Walden <tuhs at cuzuco.com> wrote:
> ....
>
> - CMU's ALGOL68S from 1978 list all these ways --
> co comment
> comment comment
> pr pragmat
> pragmat pragmat
> # (comment symbol) comment
> :: (pragmat symbol) pragmat
> (its for UNIX v6 or v7 so not surprising # is a comment)
> http://www.softwarepreservation.org/projects/ALGOL/manual/a68s.txt/view
Be careful of overthinking here. The comment in that note says was it was
for* PDP-11's *and lists V6 and V7 was *a possible target*, but it did not
say it was. Also, the Speach and Vision PDP-11/40e based systems ran a
very hacked v6 (which a special C compiler that supported CMU's csv/cret
instructions in the microcode), which would have been the target systems.
[1]
To my knowledge/memory, the CMU Algol68 compiler never ran anywhere but
Hydra (and also used custom microcode). IIRC there was some talk to move
it to *OS (Star OS for CM*) I've sent a note to dvk to see if he remembers
it otherwise. I also ask Liebensperger what he remembers, he was hacking on
*OS in those days. Again, IIRC Prof. Peter Hibbard was the mastermind
behind the CMU Algol68 system. He was a Brit from Cambridge (and taught
the parallel computing course which I took from him at the time).
FWIW: I also don't think the CMU Algol68 compiler was ever completely
self-hosting, and like BLISS, required the PDP-10 to support it. As to why
it was not moved to the Vax, I was leaving/had left by that time, but I
suspect the students involved graduated and by then the Perq's had become
the hot machine for language types and ADA would start being what the gvt
would give research $s too.
>
>
> ...
>
> But look! The very first line of that file! It is a single # sitting all
> by itself. Why? you ask. Well this is a hold over from when the C
> preprocessor was new. C orginally did not have it and was added later.
> PL/I had a %INCLUDE so Ritchie eventaully made a #include -- but pre 7th
> Edition the C preprocessor would not be inkoved unless the very first
> character of the C source file was an #
>
That was true of V7 and Typesetter C too. It was a separate program (
/lib/cpp) that the cc command called if needed.
> Since v7 the preprocessor always run on it. The first C preprocessor was
> Ritchie's work with no nested includes and no macros. v7's was by John
> Reiser which added those parts.
>
Right, this is what I was referring too last night in reference to Sean
comments. As I said, the /bin/cc command was a shell script and it peaked
at the first character to see if it was #. I still find myself starting
all C programs with a # on a line by itself ;-)
Note that the Ritchie cpp was influenced by Brian's Ratfor work, so using #
is not surprising.
This leads to a question/thought for this group, although I think needs to
move to COFF (which I have CC'ed for follow up).
I have often contended, that one of the reasons why C, Fortran, and PL/1
were so popular as commercial production languages were because they could
be preprocessed. For a commercial place where lots of different targets is
possible, that was hugely important. Pascal, for instance, has semantics
that makes writing a preprocessor like cpp or Ratfor difficult (which was
one of the things Brian talks about in his "*Why Pascal is not my favorite
Programming Language <http://www.lysator.liu.se/c/bwk-on-pascal.html>*"
paper). [2]
So, if you went to commercial ISV's and looked at what they wrote in. It
was usually some sort of preprocessed language. Some used Ratfor like a
number of commercial HPC apps vendors, Tektronix wrote PLOT10 in MORTRAN.
I believe it was Morgan-Stanley had a front-end for PL/1, which I can not
recall the name. But you get the point ... if you had to target different
runtime environments, it was best for your base code to not be specific.
However ... as C became the system programming language, the preprocessor
was important. In fact, it even gave birth the other tools like autoconfig
to help control them. Simply, the idiom:
#ifdef SYSTEMX
#define SOME_VAR (1)
... do something specific
#endif /* SYSTEMX */
While loathsome to read, it actually worked well in practice.
That fact is I hate the preprocessor in many ways but love it for what it
for the freedom it actually gave us to move code. Having programmed since
the 1960s, I remember how hard it was to move things, even if the language
was the same.
Today, modern languages try to forego the preprocessor. C++'s solution is
to throw the kitchen sink into the language and have 'frameworks', none of
which work together. Java's and its family tries to control it with the
JVM. Go is a little too new to see if its going to work (I don't see a lot
of production ISV code in it yet).
Note: A difference between then and now, is 1) we have few target
architectures and 2) we have fewer target operating environments, 3) ISV
don't like multiple different versions of their SW, they much prefer very
few for maintenance reasons so they like # 1 and #2 [i.e. Cole's law of
economics in operation here].
So ... my question, particularly for those like Doug who have programmed
longer and at least as long as I, what do you think? You lived the same
time I did and know the difficulties we faced. Is the loss of a
preprocessor good or bad?
Clem
[1] Historical footnote about CMU. I was the person that brought V7 into
CMU and I never updated the Speach or Vision systems and I don't think
anyone did after I left. We ran a CMU V7 variant mostly on the 11/34s (and
later on a couple of 11/44s I believe) that had started to pop up.
Although later if it was a DEC system, CS was moving to Vaxen when they
could get the $s (but the Alto's and Perq's had become popular with the CMU
SPICE proposal). Departments like bio-engineering, mech ee, ran the
cheaper systems on-site and then networked over the Computer Center's Vaxen
and PDP-20's when they needed address space).
[2] Note: Knuth wrote "Web" to handle a number of the issues, Kernighan
talks about - but he had to use an extended Pascal superset and his program
was notable for not being portable (he wrote for it for the PDP-10
Pascal). [BTW: Ward Cunningham, TW Cook and I once counted over 8
different 'Tek Pascal' variants and 14 different 'HP Basics'].
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200108/8eda3d35/attachment.html>
From clemc at ccc.com Fri Jan 10 01:54:44 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 9 Jan 2020 10:54:44 -0500
Subject: [COFF] [TUHS] screen editors
In-Reply-To: <202001090423.0094NooZ379407@darkstar.fourwinds.com>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
<bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
<alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
<CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
<20200109012830.GC16808@mcvoy.com>
<D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
<CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
<20200109020720.GG16808@mcvoy.com>
<CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
<202001090423.0094NooZ379407@darkstar.fourwinds.com>
Message-ID: <CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
Answering, but CCing COFF if folks want to continue. This is less about
UNIX and more about how we all got to where we are.
On Wed, Jan 8, 2020 at 11:24 PM Jon Steinhart <jon at fourwinds.com> wrote:
> Clem, this seems like an unusual position for you to take. vim is
> backwards
> compatible with vi (and also ed), so it added to an existing ecosystem.
>
No, really unusually when you think about it. vim is backward compatible
except when it's not (as Bakul points out) - which is my complaint. It's
*almost* compatible and those small differences are really annoying when
you expect one thing and get something else (*i.e.* the least astonishment
principle).
The key point here is for *some people*, those few differences are not an
issue and are not astonished by them. But for *some of the rest of us*
(probably people like me that have used the program since PDP-11 days) that
only really care about the original parts, the new stuff is of little value
and so the small differences are astonishing. Which comes back to the
question of good and best. It all depends on one what you value/where you
put the high order bit. I'm not willing to "pay" for the it; as it gives
me little value.
Doug started this thread with his observation that ex/vi was huge compared
to other editors. * i.e.* value: small simple easy to understand (Rob's old
"*cat -v considered harmful*" argument if you will). The BSD argument had
always been: "the new stuff is handy." The emacs crew tends to take a
similar stand. I probably don't go quite as far as Rob, but I certainly
lean in that direction. I generally would rather something small and new
that solves a different (set of) problem(s), then adding yet another wart
on to an older program, *particularly when you change the base
functionality *- which is my vi *vs. *vim complaint*.* [i.e. 'partial
credit' does not cut it].
To me, another good example is 'more', 'less' and 'pg'. Eric Schienbrood
wrote the original more(ucb) to try to duplicate the ITS functionality (he
wrote it for the PDP-11/70 in Cory Hall BTW - Ernie did not exist and
4.1BSD was a few years in the future - so small an simple of a huge
value). It went out in the BSD tapes, people loved it and were happy. It
solved a problem as we had it. Life was good. Frankly, other than NIH,
I'm not sure why the folks at AT&T decided to create pg a few years later
since more was already in the wild, but at least it was a different program
(Mary Ann's story of vi *vs*. se if probably in the same vein). But
because of that behavior, if someone like me came to an AT&T based system
with only pg installed, so those of us that liked/were used to more(ucb)
could install it and life was good. Note pg was/is different in
functionality, it's similar, but not finger compatible.
But other folks seem to have thought neither was 'good enough' -- thus
later less(gnu) was created adding a ton of new functionality to Eric's
program. The facts are clear, some (ney many) people >>love<< that new
functionality, like going backward. I >>personally<< rarely care/need for
it, Eric's program was (is) good enough for me. Like Doug's observation
of ed *vs.* ex/vi; less is huge compared to the original more (or pg for
that matter). But if you value the new features, I suspect you might
think that's not an issue. Thanks to Moore's law, the size in this case
probably does not matter too much (other than introducing new bugs). At
least, when folks wrote did Gnu's less, the basic more(ucb) behavior was
left along and if you set PAGER=more less(gnu) pretty much works as I
expect it too. So I now don't bring Eric's program with me, the same way
Bakul describes installing nvi on new systems (an activiity I also do).
Back to vi *vs.* nvi *vs.* vim *et. al.* Frankly, in my own case, I do
>>occaisonally<< use split screens, but frankly, I can get most of the same
from having a window manager, different iterm2 windows and cut/paste. So
even that extension to nvi, is of limited value to me. vim just keeps
adding more and more cruft and its even bigger. I personally don't care
for the new functionality, and the size of it all is worrisome. What am I
buying? That said, if the new features do not hurt me, then I don't really
care. I might even use some of the new functionality - hey I run mac OS
not v7 or BSD 4.x for my day to day work and I do use the mac window
manager, the browser *et al*, but as I type this message I have 6 other
iterm2 windows open with work I am doing in other areas.
Let me take a look at this issue in a different way. I have long been a
'car guy' and like many of those times in my youth spent time and money
playing/racing etc. I've always thought electric was a great idea/but there
has been nothing for me. Note: As many of you know my work in computers has
been in HPC, and I've been lucky to spend a lot of time with my customers,
in the auto and aerospace industry (*i.e.* the current Audi A6 was designed
on one of my supercomputer systems). The key point is have tended to
follow technology in their area and tend to "in-tune" with a lot of
developments. The result, except for my wife's minivan (that she preferred
in the years when our kids were small), I've always been a
die-hard German-engineered/performance car person. But when Elon announced
the Model 3 (like 1/2 the techie world), I put down a deposit and waited.
Well why I was waiting, my techie daughter (who also loves cars), got a
chance to drive one. She predicted I would hate it!!! So when my ticket
finally came up, I went to drive them. She was right!!! With the Model 3,
you get a cool car, but it's about the size of a Corrolla. Coming from
Germans cars for the last 35 years, the concept of spending $60K US in
practice for a Corrolla just did not do it for me. I ended up ordering the
current Unixmobile, my beloved Tesla Model S/P100D.
The truth is, I paid a lot of money for it but I *value *what I got for my
money. A number of people don't think it's worth it. I get that, but I'm
still happy with what I have. Will there someday be a $20K electric car
like my Model S? While I think electric cars will get there (I point out
the same price curve on technology such microwave ovens from the 1970so
today), but I actually doubt that there will be a $20K electric vehicle
like my Model S.
The reason is that to sell this car because it as to be expensive for
technology-based reasons, so Tesla had to add a lot of 'luxury' features
like other cars in the class, other sports cars, Mercedes, *et al*. As
they removed them (*i.e.* the Model 3) you still get a cool car, but it's
not at all the same as the Model S. So the point is, if I wanted an
electric car, I had to choose between a performance/luxury *vs*.
size/functionality. I realized I valued the former (and still do), but I
understand not everyone does or will.
Coming back to our topic, I really don't think this is a 'get my lawn'
issue as much, as asking someone what they really value/what they really
need. If you place a high-value you something, you will argue that its
best; if it has little value you will not.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200109/6847239f/attachment.html>
From clemc at ccc.com Fri Jan 10 06:01:34 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 9 Jan 2020 15:01:34 -0500
Subject: [COFF] [TUHS] screen editors
In-Reply-To: <20200109190219.bdHOi%steffen@sdaoden.eu>
References: <CAMYpm86i7RkeBY6oYfoZEuO3gQoSDLJ0O-HNBuKOQOKEzcSCOQ@mail.gmail.com>
<bbeafd3f-786c-fe60-cf87-0f7e202025f7@case.edu>
<alpine.BSF.2.21.9999.2001091020340.40155@aneurin.horsfall.org>
<CANCZdfriS_9BHA0V8FJe-dWCD59LoR+7K=LF+FQLp-N7zcZnHg@mail.gmail.com>
<20200109012830.GC16808@mcvoy.com>
<D192F5A5-2A67-413C-8F5C-FCF195151E4F@bitblocks.com>
<CAC20D2OFUCMYuMwux3w9M6OYpt0YFVOn+zYW7FV48rM8zLw9UA@mail.gmail.com>
<20200109020720.GG16808@mcvoy.com>
<CAC20D2PxAbWtTFpMJJ-k8cKXasSw9hDk-fb2XVdRoT2xku8wSg@mail.gmail.com>
<202001090423.0094NooZ379407@darkstar.fourwinds.com>
<CAC20D2NnR81koGXkGydDxHgzK-P+NzYDf3oX2vwXnbK0kArOAg@mail.gmail.com>
<20200109190219.bdHOi%steffen@sdaoden.eu>
Message-ID: <CAC20D2N_Md6FvANn7JTRihHe__uGNb7R5-dSVkmLTryYY4UZjw@mail.gmail.com>
Steffen - I think your reply just proved my point. I am as asking people
what they really value/what they really need. Clearly, you and I value
different things. And that is fine. You can disagree with my choices, but
accept it is what *I value*, and I understand *you value something
different*.
FWIW: I will not identify who sent it me because he sent it to me
privately, but someone else commented to me on my post that I had nailed
it. He observed "I see this sort of not respecting other people's choices
as a general trend these days. We want tolerance for our *views* but at the
same time, we are becoming more intolerant of *other* people's views!"
For a smile, this was yesterdays comic and expresses the issue well:
https://www.comicskingdom.com/brilliant-mind-of-edison-lee/2020-01-08
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200109/3747999e/attachment-0001.html>
From lars at nocrew.org Sat Jan 11 03:45:51 2020
From: lars at nocrew.org (Lars Brinkhoff)
Date: Fri, 10 Jan 2020 17:45:51 +0000
Subject: [COFF] [TUHS] Tech Sq elevator
In-Reply-To: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu> (Noel Chiappa's
message of "Fri, 10 Jan 2020 12:27:47 -0500 (EST)")
References: <20200110172747.90BDE18C09E@mercury.lcs.mit.edu>
Message-ID: <7wd0brmchc.fsf@junk.nocrew.org>
Noel Chiappa writes:
> The code is still extant, in 'SYSTEM; TV >'. It only worked (I think)
> from Knight TV keyboards
(This isn't TUHS material, but I can't resist. CC to COFF.)
There is also a Chaosnet service to call for the elevator or open the
door, so it can be used remotely. The ITS program ESCE uses this
service. I suppose there must have been something for the Lisp machines
too, maybe even a Super-Hyper-Cokebottle keyboard command.
From wkt at tuhs.org Mon Jan 13 10:49:12 2020
From: wkt at tuhs.org (Warren Toomey)
Date: Mon, 13 Jan 2020 10:49:12 +1000
Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <202001130044.00D0ilcV616661@darkstar.fourwinds.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
<CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
<202001122340.00CNeef0604557@darkstar.fourwinds.com>
<AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
<202001130044.00D0ilcV616661@darkstar.fourwinds.com>
Message-ID: <20200113004912.GA27610@minnie.tuhs.org>
All, can we move this not-really-Unix discussion to COFF?
Thanks, Warren
P.S A bit more self-regulation too, please. You shouldn't need me to point
out when the topic has drifted so far :-)
From crossd at gmail.com Mon Jan 13 11:23:11 2020
From: crossd at gmail.com (Dan Cross)
Date: Sun, 12 Jan 2020 20:23:11 -0500
Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: <AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
<CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
<202001122340.00CNeef0604557@darkstar.fourwinds.com>
<AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
Message-ID: <CAEoi9W5Qo4-ia6VAQn79pdhoZ4BKF3+qzL8xQhuYoAiEMcq+Zg@mail.gmail.com>
-TUHS, +COFF, in line with Warren's wishes.
On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah <bakul at bitblocks.com> wrote:
> There is similar code in FreeBSD kernel. Embedding head and next ptrs
> reduces
> memory allocation and improves cache locality somewhat. Since C doesn't
> have
> generics, they try to gain the same functionality with macros. See
>
> https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h
>
> Not that this is the same as what Linux does (which I haven't dug into) but
> I suspect they may have had similar motivation.
>
I was actually going to say, "blame Berkeley." As I understand it, this
code originated in BSD, and the Linux implementation is at least inspired
by the BSD code. There was code for singly and doubly linked lists, queues,
FIFOs, etc.
I can actually understand the motivation: lists, etc, are all over the
place in a number of kernels. The code to remove an element from a list is
trivial, but also tedious and repetitive: if it can be wrapped up into a
macro, why not do so? It's one less thing to mess up.
I agree it's gone off the rails, however.
- Dan C.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200112/b3fa8f64/attachment.html>
From bakul at bitblocks.com Mon Jan 13 11:41:06 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Sun, 12 Jan 2020 17:41:06 -0800
Subject: [COFF] [TUHS] Tech Sq elevator [ really type-checking ]
In-Reply-To: Your message of "Sun, 12 Jan 2020 20:23:11 -0500."
<CAEoi9W5Qo4-ia6VAQn79pdhoZ4BKF3+qzL8xQhuYoAiEMcq+Zg@mail.gmail.com>
References: <202001122225.00CMPc9S085970@tahoe.cs.Dartmouth.EDU>
<CAK7dMtBHfc35vb+5XP6WcBXDKsFyMxFSZ8vfgen7_5jgrnNxnQ@mail.gmail.com>
<202001122340.00CNeef0604557@darkstar.fourwinds.com>
<AB452025-FCE9-4D41-992A-D3135683A6D6@bitblocks.com>
<CAEoi9W5Qo4-ia6VAQn79pdhoZ4BKF3+qzL8xQhuYoAiEMcq+Zg@mail.gmail.com>
Message-ID: <20200113014113.DB51E156E42E@mail.bitblocks.com>
On Sun, 12 Jan 2020 20:23:11 -0500 Dan Cross <crossd at gmail.com> wrote:
>
> -TUHS, +COFF, in line with Warren's wishes.
>
> On Sun, Jan 12, 2020 at 7:36 PM Bakul Shah <bakul at bitblocks.com> wrote:
>
> > There is similar code in FreeBSD kernel. Embedding head and next ptrs
> > reduces
> > memory allocation and improves cache locality somewhat. Since C doesn't
> > have
> > generics, they try to gain the same functionality with macros. See
> >
> > https://github.com/freebsd/freebsd/blob/master/sys/sys/queue.h
> >
> > Not that this is the same as what Linux does (which I haven't dug into) but
> > I suspect they may have had similar motivation.
> >
>
> I was actually going to say, "blame Berkeley." As I understand it, this
> code originated in BSD, and the Linux implementation is at least inspired
> by the BSD code. There was code for singly and doubly linked lists, queues,
> FIFOs, etc.
>
> I can actually understand the motivation: lists, etc, are all over the
> place in a number of kernels. The code to remove an element from a list is
> trivial, but also tedious and repetitive: if it can be wrapped up into a
> macro, why not do so? It's one less thing to mess up.
In late '90s when I first came across code in the FreebSD
kernel, as a Scheme-phile I instinctively disliked it. But upon
reflection and considering doing it the lisp way -- car,cdr,
where car points to a data stucture, I realized this was better,
The list way wouldn't have helped and made things worse. Now
you may have to either cast the car (whose type would've been
void*, which loses type safety) or define data structure
specific types and you are back to needing lots of very
similar functions. In addition you may now have to lock more
data structures to manage these lists. Then consider what
happens when an object is on multiple lists. Now you need O(n)
operations to remove it from all the lists. And so on.
> I agree it's gone off the rails, however.
Well, this is "historic unix code" :-)
From sauer at technologists.com Wed Jan 15 05:29:52 2020
From: sauer at technologists.com (Charles H Sauer)
Date: Tue, 14 Jan 2020 13:29:52 -0600
Subject: [COFF] Glenn Henry's Museum
Message-ID: <96ef1017-7f57-046a-620e-7e4cfbc88850@technologists.com>
A post in a Facebook IBM retirees group of an IBM PC museum (in
Germany?) made be follow up with reference to Glenn's museum. Glenn
showed me around the museum last time I saw him at Centaur, but I did
not know until today about the Web presence at http://www.glennsmuseum.com/.
Rise of the Centaur (https://www.imdb.com/title/tt5690958/) includes
Glenn discussing some of the museum.
Charlie
--
voice: +1.512.784.7526 e-mail: sauer at technologists.com
fax: +1.512.346.5240 Web: https://technologists.com/sauer/
Facebook/Google/Skype/Twitter: CharlesHSauer
From rudi.j.blom at gmail.com Wed Jan 15 16:09:40 2020
From: rudi.j.blom at gmail.com (Rudi Blom)
Date: Wed, 15 Jan 2020 13:09:40 +0700
Subject: [COFF] Glenn Henry's Museum
Message-ID: <CAMYpm86D_2wOxRj6B521MFCRXVxNLPBOj2G4DNV36ggLB8njEg@mail.gmail.com>
>From the museum pages via the KG-84 picture to wiki. Reading a bit on
crypto devices, stumbling over M-209 and
"US researcher Dennis Ritchie has described a 1970s collaboration with
James Reeds and Robert Morris on a ciphertext-only attack on the M-209
that could solve messages of at least 2000–2500 letters.[3] Ritchie
relates that, after discussions with the NSA, the authors decided not
to publish it, as they were told the principle was applicable to
machines then still in use by foreign governments.[3]"
https://en.wikipedia.org/wiki/M-209
The paper
https://cryptome.org/2015/12/ReedsTheHagelinCipherBellLabs1978.pdf
ends with
"The program takes about two minutes to produce a solution on a DEC PDP-11/70."
No info on the program coding.
More info around the story from Richie himself
https://www.bell-labs.com/usr/dmr/www/crypt.html
From cym224 at gmail.com Sat Jan 18 08:09:37 2020
From: cym224 at gmail.com (Nemo Nusquam)
Date: Fri, 17 Jan 2020 17:09:37 -0500
Subject: [COFF] Troff usage
Message-ID: <cd544f70-c099-6341-b24f-73975349b2b4@gmail.com>
Originally, I meant to reply to the Linux-origins thread by pointing to
AST's take on the matter but I failed to find it. So, instead, here is
something to warm the cockles of troff users:
From https://www.cs.vu.nl/~ast/home/faq.html
Q: What typesetting system do you use?
A: All my typesetting is done using troff. I don't have any need to see
what the output will look like. I am quite convinced that troff will
follow my instructions dutifully. If I give it the macro to insert a
second-level heading, it will do that in the correct font and size, with
the correct spacing, adding extra space to align facing pages down to
the pixel if need be. Why should I worry about that? WYSIWYG is a step
backwards. Human labor is used to do that which the computer can do
better. Also, using troff means that the text is in ASCII, and I have a
bunch of shell scripts that operate on files (whole chapters) to do
things like produce a histogram by year of all the references. That
would be much harder and slower if the text were kept in some
manufacturer's proprietary format.
Q: What's wrong with LaTeX?
A: Nothing, but real authors use troff.
N.
From andreww591 at gmail.com Sat Jan 18 17:30:09 2020
From: andreww591 at gmail.com (Andrew Warkentin)
Date: Sat, 18 Jan 2020 00:30:09 -0700
Subject: [COFF] [TUHS -> COFF] Distributed systems,
was: On the origins of Linux - "an academic question"
In-Reply-To: <CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
References: <CAD-qYGqpFtgAMSa+Ypn5gzcEsK0dNVJ3B4AHWgjLfoaLhBpdUg@mail.gmail.com>
<CAKzdPgz5pfeCsG61XG9Fj6UxAuTBDVYnBNQzQJB3JfQ8GKyBNg@mail.gmail.com>
Message-ID: <CAD-qYGqDU_ikweP0yWshkarbmrHViSPX63OHKBfqAOpz8iFfTQ@mail.gmail.com>
On 1/17/20, Rob Pike <robpike at gmail.com> wrote:
> I am convinced that large-scale modern compute centers would be run very
> differently, with fewer or at least lesser problems, if they were treated
> as a single system rather than as a bunch of single-user computers ssh'ed
> together.
>
> But history had other ideas.
>
[moving to COFF since this isn't specific to historic Unix]
For applications (or groups of related applications) that are already
distributed across multiple machines I'd say "cluster as a single
system" definitely makes sense, but I still stand by what I said
earlier about it not being relevant for things like workstations, or
for server applications that are run on a single machine. I think
clustering should be an optional subsystem, rather than something that
is deeply integrated into the core of an OS. With an OS that has
enough extensibiity, it should be possible to have an optional
clustering subsystem without making it feel like an afterthought.
That is what I am planning to do in UX/RT, the OS that I am writing.
The "core supervisor" (seL4 microkernel + process server + low-level
system library) will lack any built-in network support and will just
have support for local file servers using microkernel IPC. The network
stack, 9P client filesystem, 9P server, and clustering subsystem will
all be separate regular processes. The 9P server will use regular
read()/write()-like APIs rather than any special hooks (there will be
read()/write()-like APIs that expose the message registers and shared
buffer to make this more efficient), and similarly the 9P client
filesystem will use the normal API for local filesystem servers (which
will also use read()/write() to send messages). The clustering
subsystem will work by intercepting process API calls and forwarding
them to either the local process server or to a remote instance as
appropriate. Since UX/RT will go even further than Plan 9 with its
file-oriented architecture and make process APIs file-oriented, this
will be transparent to applications. Basically, the way that the
file-oriented process API will work is that every process will have a
special "process server connection" file descriptor that carries all
process server API calls over a minimalist form of RPC, and it will be
possible to redirect this to an intermediary at process startup (of
course, this redirection will be inherited by child processes
automatically).
From clemc at ccc.com Wed Jan 22 07:52:04 2020
From: clemc at ccc.com (Clem Cole)
Date: Tue, 21 Jan 2020 16:52:04 -0500
Subject: [COFF] [TUHS] Unix on Zilog Z8000?
In-Reply-To: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
Message-ID: <CAC20D2OWXcLV8CZBRZqK8SDJ5+kNcHEJh-43Fb7dqob1eQUm4A@mail.gmail.com>
Moving to COFF
On Tue, Jan 21, 2020 at 12:53 PM Jon Forrest <nobozo at gmail.com> wrote:
> As I remember the Z8000 was going to be the great white hope that
> would continue Zilog's success with the Z80 into modern times.
> But, it obviously didn't happen.
>
> Why?
>
A really good question. I will offer my opinion as someone that lived
through the times.
The two contemporary chips of that time were the Intel 8086 and Z8000.
Certainly, between those two, the Zilog chip was a better chip from a
software standpoint. The funny part was that Moto had been pushing the
6809 against those two. The story of the IBM/PC and Moto is infamous.
Remember the 68K is a skunkworks project and is not something they were
talking about it.
Why IBM picked 8086/8088 over Z8000 I do not know. I'm >>guessing<< total
system cost and maybe vendor preference. The tea, that developed the PC
had been using the 8085 for another project, so the jump of vendors to
Zilog would have been more difficult (Moto and IBM corporate had been tight
for years, MECL was designed by Moto for IBM for the System 360). I do
know they picked Intel over the 6809, even though they had the X-series
device in Yorktown (just like we had it at Tektronix) and had wanted to use
what would become the 68000.
In the end, other than Forest's scheme, none of them could do VM without a
lot of help. If I had not known about the X-series chip (or had been given
a couple of them), I think Roger and I would have used the Z8000 for
Magnolia. But I know Roger and I liked it better; as did most of our
peeps in Tek Labs at the time. IIRC Our thinking was that Z8000 has an
"almost" good enough instruction set, but since many of the processors's
addressing modes are missing on some/most of the instructions, it makes
writing a compiler more difficult (Bill Wulf used to describe this as an
'irregular' instruction set). And even though the address space was large,
you still had to contend with a non-linear segmented address scheme.
So I think once the 68000 came on the scene for real, it had the advantage
if the best instructions set (all instructions worked as expected, was
symmetric) and looked pretty darned near a PDP-11. The large linear
address was a huge win and even though it was built as a 16-bit chip
internally (i.e. 16-bit barrel shifter and needing 2 ticks for all 32-bit
ops), all the registers were defined as 32-bits wide. I think we saw it
as becoming a full 32-bit device the soonest and with the least issues.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200121/989ea1f8/attachment.html>
From wobblygong at gmail.com Wed Jan 22 14:39:17 2020
From: wobblygong at gmail.com (Wesley Parish)
Date: Wed, 22 Jan 2020 17:39:17 +1300
Subject: [COFF] The Third Ronnie's SDI's embedded systems
Message-ID: <CACNPpeZumGQn1sz8PbC7AuvTEC+xOnTGUVV5UZ1Vxkgtk65c_A@mail.gmail.com>
Hi
This isn't precisely Unix-related, but I'm wondering about the Third
Ronnie's SDI's embedded systems. Is there anyone alive who knows just
what they were? I'm also wondering, since the "Star Wars" program
seemed to go off the boil at the end of the "Cold War", and the
embedded systems were made with the US taxpayer's dollar, whether or
not they are now public domain - since iirc, US federal law mandates
that anything made with the taxpayer's dollar is owned by the taxpayer
and is thus in the public domain. I'm wondering about starting a
Freedom of Information request to find all of that out, but I don't
quite know how to go about it. (FWVLIW, I'm a fan of outer space
exploration (and commercial use) and a trove of realtime, embedded
source code dealing with satellites would be a treasure indeed. It'd
raise the bar and lower the cost of entry into that market.)
Also, more Unixy, what status at the time were the POSIX realtime
standards, and what precise relation did they have to Unix?
Thanks
Wesley Parish
From clemc at ccc.com Thu Jan 23 04:42:34 2020
From: clemc at ccc.com (Clem Cole)
Date: Wed, 22 Jan 2020 13:42:34 -0500
Subject: [COFF] [TUHS] Apollo Domain/OS
In-Reply-To: <25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
<DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
<CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
<20200121230025.GL15860@mit.edu>
<CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>
<CABH=_VS6mEDC1gorq44T98P0CyfnvjNqjpUJFWbbSjdq7bAUMQ@mail.gmail.com>
<25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org>
Message-ID: <CAC20D2NQOcd9adkOtczKG8KKK1p-ii66_48-vUr1-eHOepKfRA@mail.gmail.com>
moving to COFF
On Wed, Jan 22, 2020 at 1:06 PM Pete Wright <pete at nomadlogic.org> wrote:
> I also seem to remember him telling me about working on the patriot
> missile system, although i am not certain if i am remembering correctly
> that this was something he did at apollo or at another company in the
> boston area.
>
The Patriot was/is Raytheon in Andover, MA not Apollo (Chelmsford - two
towns west). Cannot speak for today, but when it was developed the source
code was in Ada. I knew the Chief Scientist/PI for the original Patriot
system (who died of a massive stroke a few years back -- my wife used to
take care of his now 30-40 yo kids when they were small and she was a tad
younger).
During the first Gulf War, he basically did not sleep the whole first
month. As I understand it, Raytheon normally took 3-6 months per SW
release. During the war, they put out an update every couple of days and
Willman once said they were working non-stop on the codebase, dealing with
issues they have never seen or have been simulated. I gather it was quite
exciting ... sigh. We got him to give a couple of talks at some local
IEEE functions describing the SW engineering process they had used.
Willman was one of the people that got me to respect Ada and the job his
folks had to do. To once told me, that at some point, Raytheon had a
contract supporting the Polaris System for the US Navy. The Navy had long
ago lost the source. They had disassembled and were patching what they
had. Yeech!!!! He also once made another comment to me ( in the late
1980s IIRC) that the DoD wanted Ada because they want the source to be part
of the specifications and wanted a language that was more explicit that
they could use for those specs. I have no idea how much that has proven
to be true.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200122/a3db7ad2/attachment.html>
From arrigo at alchemistowl.org Thu Jan 23 04:55:19 2020
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 22 Jan 2020 19:55:19 +0100
Subject: [COFF] Book about the Sprint/Spartan ("Safeguard")
hardware/software
In-Reply-To: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org>
References: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org>
Message-ID: <0B3DD4D1-26E0-4774-8CEB-E38D4556CF70@alchemistowl.org>
Quoting myself.. sorry
> On 22 Jan 2020, at 19:47, Arrigo Triulzi <arrigo at alchemistowl.org> wrote:
>
> Does anyone know if there is a book or in-depth article about the Sprint/Spartan system, named Safeguard, hardware and software?
>
> There is very little about it available online (see http://www.nuclearabms.info/Computers.html) but it was apparently an amazing programming effort running on UNIVAC.
I should have added that there is some material online here:
https://www.srmsc.org/dps2010.html
Linking to this Bell Labs history paper:
https://www.srmsc.org/ref1040.html
(and some contributions from specific authors about their subsystems).
Arrigo
From arrigo at alchemistowl.org Thu Jan 23 04:47:12 2020
From: arrigo at alchemistowl.org (Arrigo Triulzi)
Date: Wed, 22 Jan 2020 19:47:12 +0100
Subject: [COFF] Book about the Sprint/Spartan ("Safeguard") hardware/software
Message-ID: <414C850D-093F-47CA-A6E3-12EF9F01D511@alchemistowl.org>
Does anyone know if there is a book or in-depth article about the Sprint/Spartan system, named Safeguard, hardware and software?
There is very little about it available online (see http://www.nuclearabms.info/Computers.html) but it was apparently an amazing programming effort running on UNIVAC.
Arrigo
From krewat at kilonet.net Thu Jan 23 05:41:56 2020
From: krewat at kilonet.net (Arthur Krewat)
Date: Wed, 22 Jan 2020 14:41:56 -0500
Subject: [COFF] The Third Ronnie's SDI's embedded systems
In-Reply-To: <CACNPpeZumGQn1sz8PbC7AuvTEC+xOnTGUVV5UZ1Vxkgtk65c_A@mail.gmail.com>
References: <CACNPpeZumGQn1sz8PbC7AuvTEC+xOnTGUVV5UZ1Vxkgtk65c_A@mail.gmail.com>
Message-ID: <eaccc7c0-262f-ad9b-f3c1-1ec128221a9a@kilonet.net>
I highly doubt sensitive or classified military information would be
given to the public, just because they "own" it. ;)
Somewhat SDI related side-story:
My only experience with Apollo/Domain OS systems was at a defense
contractor I was consulting for back in the mid-to-late 90's. I was the
Sun system administrator for the Mechanical and Electrical Engineering
departments, and because I knew VMS somewhat, I also took on some VAX
work from them too... Mostly keeping old systems running like
VAXstations and a micro-VAX or two, plus an 8350.
Anyway, one day, an older wizened engineer came to me to ask if I could
take a look at something. He was very agitated. They had an old Apollo
setup, a few diskless workstations, plus a "file server" that actually
had one or two disk drives in it. But still, basically a workstation.
They had more workstations "back in the day" but they all died one by
one, and were not on support so they just threw them away.
The file server had died years back, and the workstations were of course
useless, but the older engineers held onto them for some reason, mostly
nostalgia I think.
Checking out the file server, the power supply was obviously dead, so I
pulled a power supply from one of the remaining workstations, and it
fired right up. After figuring out the token ring wiring, and jumping
wires where workstations had been removed, I powered on one of the
workstations, and it booted and ran just fine.
The old engineering wizard went back to his notes, found his password
and everything else he needed, and proceeded to find a few files that
were obviously very important to him. I don't remember the transfer
method, maybe it was floppies... The system certainly wasn't hooked up
to any other network in the building.
Anyway, he was very happy. He explained the files were PCB layouts for
some old project they were involved in, and needed the files to prove
the work they did, so they could get paid.
It was an SDI project. ;)
Moral of the story, defense contractors were still reaping the rewards
of SDI, at least 10-15 years later.
This was at Loral Fairchild Systems in Syosset, NY, an east-coast
division (and originally corporate headquarters ) of Fairchild Systems
of California, which used to be Fairchild Imaging. Bought by Lockheed
Martin a few years later. And then sold off to BAE after that. I only
stuck around until 2000 or so, just before the sell-off to BAE.
When I first went to interview for the consulting gig back in 1993, I
was shown around to meet all the engineers. They all had drawings of
PCBs on their cubicle walls... they were all round boards. I hit it off
with one of the electrical engineers right away, and I asked him what
they were. He looked around, and said in a low voice: "They fit into a
missile". Later on I came to realize they were working on proposals for
THAADS. One of their hurdles was calibrating CCDs for IR use. Every cell
in their CCDs were slightly different in terms of light response. The
engineer I had hit it off with was the principal engineer responsible
for coming up with a method of calibrating IR CCDs all in hardware.
art k.
On 1/21/2020 11:39 PM, Wesley Parish wrote:
> Hi
>
> This isn't precisely Unix-related, but I'm wondering about the Third
> Ronnie's SDI's embedded systems. Is there anyone alive who knows just
> what they were? I'm also wondering, since the "Star Wars" program
> seemed to go off the boil at the end of the "Cold War", and the
> embedded systems were made with the US taxpayer's dollar, whether or
> not they are now public domain - since iirc, US federal law mandates
> that anything made with the taxpayer's dollar is owned by the taxpayer
> and is thus in the public domain. I'm wondering about starting a
> Freedom of Information request to find all of that out, but I don't
> quite know how to go about it. (FWVLIW, I'm a fan of outer space
> exploration (and commercial use) and a trove of realtime, embedded
> source code dealing with satellites would be a treasure indeed. It'd
> raise the bar and lower the cost of entry into that market.)
>
> Also, more Unixy, what status at the time were the POSIX realtime
> standards, and what precise relation did they have to Unix?
>
> Thanks
>
> Wesley Parish
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
From pete at nomadlogic.org Thu Jan 23 04:51:21 2020
From: pete at nomadlogic.org (Pete Wright)
Date: Wed, 22 Jan 2020 10:51:21 -0800
Subject: [COFF] [TUHS] Apollo Domain/OS
In-Reply-To: <CAC20D2NQOcd9adkOtczKG8KKK1p-ii66_48-vUr1-eHOepKfRA@mail.gmail.com>
References: <CAEoi9W4o-qPs9JskMCmca+c9M3pqcmL3kPcANQ4Jb=cwJkVkSg@mail.gmail.com>
<DEE23024-04E3-4A37-AD17-41EC725B8B0A@eschatologist.net>
<CAC20D2MBb=UavxQkePdvC20W7WJUEaw9xcuGQGh-c=2rkAxP_Q@mail.gmail.com>
<20200121230025.GL15860@mit.edu>
<CAFH29tpWuSsx8V6ErSCXP_JU6wS9m18KQFFCciKYiUbJd5TUjA@mail.gmail.com>
<CABH=_VS6mEDC1gorq44T98P0CyfnvjNqjpUJFWbbSjdq7bAUMQ@mail.gmail.com>
<25618b7a-d831-fd56-80fb-41da1f65887f@nomadlogic.org>
<CAC20D2NQOcd9adkOtczKG8KKK1p-ii66_48-vUr1-eHOepKfRA@mail.gmail.com>
Message-ID: <fdb161ab-6b8d-3b8c-2e46-511da490c675@nomadlogic.org>
On 2020-01-22 10:42, Clem Cole wrote:
> moving to COFF
>
> On Wed, Jan 22, 2020 at 1:06 PM Pete Wright <pete at nomadlogic.org
> <mailto:pete at nomadlogic.org>> wrote:
>
> I also seem to remember him telling me about working on the patriot
> missile system, although i am not certain if i am remembering
> correctly
> that this was something he did at apollo or at another company in the
> boston area.
>
> The Patriot was/is Raytheon in Andover, MA not Apollo (Chelmsford -
> two towns west).  Cannot speak for today, but when it was developed
> the source code was in Ada. Â I knew the Chief Scientist/PI for the
> original Patriot system (who died of a massive stroke a few years back
> -- my wife used to take care of his now 30-40 yo kids when they were
> small and she was a tad younger).
>
> During the first Gulf War, he basically did not sleep the whole first
> month.  As I understand it, Raytheon normally took 3-6 months per SW
> release. During the war, they put out an update every couple of days
> and Willman once said they were working non-stop on the codebase,
> dealing with issues they have never seen or have been simulated. I
> gather it was quite exciting ... sigh.  We got him to give a couple
> of talks at some local IEEE functions describing the SW
> engineering process they had used.
>
> Willman was one of the people that got me to respect Ada and the job
> his folks had to do. To once told me, that at some point, Raytheon had
> a contract supporting the Polaris System for the US Navy.  The Navy
> had long ago lost the source. Â They had disassembled and were patching
> what they had. Yeech!!!! He also once made another comment to me ( in
> the late 1980s IIRC) that the DoD wanted Ada because they want the
> source to be part of the specifications and wanted a language that was
> more explicit that they could use for those specs.  I have no idea
> how much that has proven to be true.
Thanks Clem - that's really insightful. I remember him telling me that
during testing they would have to shut down one of the main highways
through Arizona and how stressful it was trying to get software and
hardware to play nice while produce was literally rotting on the
highway. I'm sure he told me more stories but that image of a bunch of
engineering sweating it out in the desert really stood out in my mind.
-pete
--
Pete Wright
pete at nomadlogic.org
@nomadlogicLA
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200122/2e1e5939/attachment-0001.html>
From peter at rulingia.com Thu Jan 23 15:27:02 2020
From: peter at rulingia.com (Peter Jeremy)
Date: Thu, 23 Jan 2020 16:27:02 +1100
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
Message-ID: <20200123052702.GA83898@server.rulingia.com>
=> coff since it's non-Unix
On 2020-Jan-22 13:42:44 -0500, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>Pretty interesting machine, if you study its instruction set, BTW; with no
>stack, subroutines are 'interesting'.
"no stack" was fairly standard amongst early computers. Note the the IBM
S/360 doesn't have a stack..
The usual approach to subroutines was to use some boilerplate as part of the
"call" or function prologue that stashed a return address in a known
location (storing it in the word before the function entry or patching the
"return" branch were common aproaches). Of course this made recursion
"hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at
least of that vintage) normally don't support recursion for that reason.
--
Peter Jeremy
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 963 bytes
Desc: not available
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/49fbaae1/attachment.sig>
From clemc at ccc.com Fri Jan 24 00:08:24 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 23 Jan 2020 09:08:24 -0500
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <20200123052702.GA83898@server.rulingia.com>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
<20200123052702.GA83898@server.rulingia.com>
Message-ID: <CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com>
FWIW: System 360 uses what was called the 'push down save area' as part of
the function calling convention. Each routine declared and creates local
storage for the registers. Being reentrant was certainly possible and
many languages such as the Algol and APL families were. It's funny since
S/360 was the first architecture I knew deeply (*i.e.* got paid to
program), and working on support for York/APL at the time (and began
learning the Univac 1100 too), I just thought this was natural until I
began to learn about other processors ISA's like the PDP-11 family that had
an SP.
I remember, thinking -- this is so cool.
But as you said, originally early Fortran and Cobol didn't require same.
The typical calling conventions was something like this was pretty standard
for the S/360:
WORKAREA DSECT , Reentrant work area (stack like function)
DS 18F Save area
FIELD1 DS F Some variable
FIELD2 DS F Another variable
WORKLEN EQU *-WORKAREA Length of reentrant work area
SUBRTN1 RSECT , HLASM will perform reentrant checking
STM R14,R12,12(R13) Save registers at entry
LR R12,R15 Set code base register
USING SUBRTN1,R12 Establish code addressability
LGHI R0,WORKLEN Get length of reentrant work area
STORAGE OBTAIN, Obtain reentrant work area
X
LENGTH=(0) ..Length is in R0
ST R1,8(,R13) Forward chain in prev save area
ST R13,4(,R1) Backward chain in next save area
L R14,20(,R13) Get R1 at entry (parameters)
LR R13,R1 Set up new save area/reentrant workarea
USING WORKAREA,R13 Establish work area addressability
LM R2,R3,0(R14) Get addresses of parameters
STM R2,R3,FIELD1 Save parameter addresses for later
…
*** Subroutine Logic goes here
…
LR R1,R13 Address to be released
L R13,4(,R13) Address of prior save area
LGHI R0,WORKLEN Length of storage to release
STORAGE RELEASE, Release reentrant work area
X
ADDRESS=(1), ..Address in R1
X
LENGTH=(0) ..Length in R0
LM R14,R12,12(R13) Restore registers
OI 15(R13),X'01' This bit on means this save area
is inactive
BR R14 Return to caller
On Thu, Jan 23, 2020 at 12:47 AM Peter Jeremy <peter at rulingia.com> wrote:
> => coff since it's non-Unix
>
> On 2020-Jan-22 13:42:44 -0500, Noel Chiappa <jnc at mercury.lcs.mit.edu>
> wrote:
> >Pretty interesting machine, if you study its instruction set, BTW; with no
> >stack, subroutines are 'interesting'.
>
> "no stack" was fairly standard amongst early computers. Note the the IBM
> S/360 doesn't have a stack..
>
> The usual approach to subroutines was to use some boilerplate as part of
> the
> "call" or function prologue that stashed a return address in a known
> location (storing it in the word before the function entry or patching the
> "return" branch were common aproaches). Of course this made recursion
> "hard" (re-entrancy typically wasn't an issue) and Fortran and Cobol (at
> least of that vintage) normally don't support recursion for that reason.
>
> --
> Peter Jeremy
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/24bc73a9/attachment.html>
From clemc at ccc.com Fri Jan 24 00:31:10 2020
From: clemc at ccc.com (Clem Cole)
Date: Thu, 23 Jan 2020 09:31:10 -0500
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
<20200123052702.GA83898@server.rulingia.com>
<CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com>
Message-ID: <CAC20D2NX0DK5w-8LGOjzdGzVRZ+r1bF5xPyjbEJJVoAqT9Q4dQ@mail.gmail.com>
BTW: Not to bring up a new rat hole/new argument, but rather remind people
of one of the arguments of the day. Because of SP or no SP style of
calling, in those days the question came out language design of how the
stack or register call area was maintained: Was it/should it be the
responsibility of the calling routine or the called subroutine. Things
like Fortran's entry statement and other non-local goto's,
co-routines/setjmp/longjmp added fuel to the fire in the argument.
As a language designer/implementor at the time, someone like Steve Johnson
and Doug McIlroy were undoubtedly mixed up in the argument and had
opinions. I was certainly too inexperienced then to understand what the
fight was about. But I do remember the fight and how the issues were
taught/discussed at CMU when I was a student. I admit I was quickly sucked
into C's way of handling things, as it seemed simple/clear/understandable
to me, but not being a language person I probably did not (maybe still do
not) value some the arguments for the other side.
Clem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200123/2f617b8b/attachment.html>
From dfawcus+lists-coff at employees.org Fri Jan 24 09:50:59 2020
From: dfawcus+lists-coff at employees.org (Derek Fawcus)
Date: Thu, 23 Jan 2020 23:50:59 +0000
Subject: [COFF] Y8002 - modern Z8002 clone (was Re: Unix on Zilog Z8000?)
In-Reply-To: <CAC20D2OWXcLV8CZBRZqK8SDJ5+kNcHEJh-43Fb7dqob1eQUm4A@mail.gmail.com>
References: <f469a378-c047-2acf-e971-2734d8eced7f@gmail.com>
<CAC20D2OWXcLV8CZBRZqK8SDJ5+kNcHEJh-43Fb7dqob1eQUm4A@mail.gmail.com>
Message-ID: <20200123235059.GA61719@clarinet.employees.org>
Of all weird things, I just happened to stumble across this:
http://www.systemyde.com/proc_tab.html
specifically:
http://www.systemyde.com/pdf/y8002.pdf
Someone has reimplemented the Z8002 in Verilog HDL, and I'd guess run
it in an FPGA.
Which rather suggests there is a market for it as an embedable macro-block
in some devices, which the existing sources of Z16C01/Z16C02 are unable
to satisfy.
DF
From krewat at kilonet.net Fri Jan 24 11:18:51 2020
From: krewat at kilonet.net (Arthur Krewat)
Date: Thu, 23 Jan 2020 20:18:51 -0500
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <20200123052702.GA83898@server.rulingia.com>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
<20200123052702.GA83898@server.rulingia.com>
Message-ID: <f2657c92-d8a9-bdff-c725-f3d52c1dc19c@kilonet.net>
On 1/23/2020 12:27 AM, Peter Jeremy wrote:
> "no stack" was fairly standard amongst early computers. Note the the IBM
> S/360 doesn't have a stack..
You can make a stack out of anything ;)
From doug at cs.dartmouth.edu Fri Jan 24 01:51:31 2020
From: doug at cs.dartmouth.edu (Doug McIlroy)
Date: Thu, 23 Jan 2020 10:51:31 -0500
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <CAC20D2NX0DK5w-8LGOjzdGzVRZ+r1bF5xPyjbEJJVoAqT9Q4dQ@mail.gmail.com>
References: <20200122184244.14CBB18C083@mercury.lcs.mit.edu>
<20200123052702.GA83898@server.rulingia.com>
<CAC20D2OiPLpUQkezbG_JS-Jr20VCzM9ZgBsHAMBe-LYi4wMk6w@mail.gmail.com>
<CAC20D2NX0DK5w-8LGOjzdGzVRZ+r1bF5xPyjbEJJVoAqT9Q4dQ@mail.gmail.com>
Message-ID: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU>
Clem wrote, " the question came out language design of how the
stack or register call area was maintained: Was it/should it be the
responsibility of the calling routine or the called subroutine. Things
like Fortran's entry statement and other non-local goto's,
co-routines/setjmp/longjmp added fuel to the fire in the argument."
I don't remember much prospective discussion of the subject, but
lots of retrospective discussion of techniques that didn't
quite work, going right back to Lisp's A-list and the ensuing
"funarg problem". The first PL/I out of Hursley got it wrong, too,
but they were able to correct it before the bad way became
ingrained. In C, which had no need for closures (thunks),
efficiency was the main concern in choice of stack protocol.
The only delicate situation, longjump, was sidestepped by
doing it via library rather than language.
Doug
From bakul at bitblocks.com Sat Jan 25 10:09:12 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Fri, 24 Jan 2020 16:09:12 -0800
Subject: [COFF] [TUHS] Unix quix
In-Reply-To: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU>
References: <202001231551.00NFpVU4033383@tahoe.cs.Dartmouth.EDU>
Message-ID: <071C340F-3494-4B8D-98FD-29BF79731DB5@bitblocks.com>
I read that thunks came about as an implementation of call by name
for Algol. They were basically argument-less closures. Where as a
general closure may accept args as well as refer to values in its
environment (including those in its lexically enclosing function). I
believe at one point gcc used (argument-less) thunks when it added
support for nested functions so as to continue using a single ptr as a
function argument. A proper closure representation needs a pair (a
fun ptr & a ptr to env). The code for all this was stored on the stack &
the thunk address actually pointed to this stacked code. I guess that
had to be abandoned when storing code on stack was found to be a huge
security hole (all because of C’s lax type system & stacks growing down
to smaller addresses).
Nicklaus Wirth carefully limited the scope of functional arguments in Pascal
so as to avoid the “funarg problem†and GC. I think at least by 1975 (when I
first studied software) it was clear how to implement “reentrant†functions;
It is just that not everyone was convinced of the value of it. Even modern
RISC processors don’t actually provide any support for stacks and it is just
their “calling convention†that designates a specific GPR to be a stack ptr!
No one questions the value of subroutines (even though the register to
memory access ratio is soooo much worse now!) but closures and GC are
still not so well accepted.
On Jan 24, 2020, at 2:07 PM, Doug McIlroy <doug at cs.dartmouth.edu> wrote:
>
> Clem wrote, " the question came out language design of how the
> stack or register call area was maintained: Was it/should it be the
> responsibility of the calling routine or the called subroutine. Things
> like Fortran's entry statement and other non-local goto's,
> co-routines/setjmp/longjmp added fuel to the fire in the argument."
>
> I don't remember much prospective discussion of the subject, but
> lots of retrospective discussion of techniques that didn't
> quite work, going right back to Lisp's A-list and the ensuing
> "funarg problem". The first PL/I out of Hursley got it wrong, too,
> but they were able to correct it before the bad way became
> ingrained. In C, which had no need for closures (thunks),
> efficiency was the main concern in choice of stack protocol.
> The only delicate situation, longjump, was sidestepped by
> doing it via library rather than language.
>
> Doug
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
From dave at horsfall.org Wed Jan 29 08:18:20 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Wed, 29 Jan 2020 09:18:20 +1100 (EST)
Subject: [COFF] The MOO problem and set-uid
Message-ID: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
I recall reading in an old manpage that the (patented) set-uid bit was to
solved the MOO problem. I've searched around, but cannot find anything
relevant. Anyone know?
-- Dave
From bakul at bitblocks.com Wed Jan 29 09:01:31 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Tue, 28 Jan 2020 15:01:31 -0800
Subject: [COFF] The MOO problem and set-uid
In-Reply-To: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
Message-ID: <84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com>
The orig. ref. was in the Unix Time Sharing paper. See Section 3.5 near the end.
https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf <https://people.eecs.berkeley.edu/~brewer/cs262/unix.pdf>
The paper referenced above is behind a paywall (you can see the first page *free of charge*!)
https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380010210 <https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380010210>
One place the problem is described in some detail:
https://www.cs.unm.edu/~cris/481/gordon-moo.txt <https://www.cs.unm.edu/~cris/481/gordon-moo.txt>:
> On Jan 28, 2020, at 2:18 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
> I recall reading in an old manpage that the (patented) set-uid bit was to solved the MOO problem. I've searched around, but cannot find anything relevant. Anyone know?
>
> -- Dave
> _______________________________________________
> COFF mailing list
> COFF at minnie.tuhs.org
> https://minnie.tuhs.org/cgi-bin/mailman/listinfo/coff
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200128/08746f69/attachment.html>
From dot at dotat.at Thu Jan 30 00:50:59 2020
From: dot at dotat.at (Tony Finch)
Date: Wed, 29 Jan 2020 14:50:59 +0000
Subject: [COFF] The MOO problem and set-uid
In-Reply-To: <84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com>
References: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
<84453220-427A-45B0-9861-DC63AFFDEF9A@bitblocks.com>
Message-ID: <alpine.DEB.2.20.2001291432320.24409@grey.csi.cam.ac.uk>
Bakul Shah <bakul at bitblocks.com> wrote:
>
> The paper referenced above is behind a paywall (you can see the first
> page *free of charge*!)
> https://onlinelibrary.wiley.com/doi/abs/10.1002/spe.4380010210
That article mentions Frank King and Barry Landy who are still around in
Cambridge.
> One place the problem is described in some detail:
> https://www.cs.unm.edu/~cris/481/gordon-moo.txt
A correction: Titan was not a Unix system :-) It was a variant of the
Ferranti Atlas, with its own timesharing operating system. But it has some
second-hand Unix connections: it was the first system to have hashed
passwords, which Unix later adopted. Stephen Bourne used Titan when
developing Algol 68C.
Tony.
--
f.anthony.n.finch <dot at dotat.at> http://dotat.at/
Forties, Cromarty: West backing southwest later, 5 to 7. Moderate or rough.
Occasional rain. Good, occasionally moderate.
From jpl.jpl at gmail.com Thu Jan 30 07:17:19 2020
From: jpl.jpl at gmail.com (John P. Linderman)
Date: Wed, 29 Jan 2020 16:17:19 -0500
Subject: [COFF] Huffman - What did he do when he wasn't coding?
Message-ID: <CAC0cEp8TcK0mbkbEQ8irvSG+UcoVBMR1yvvevrYjo8PvATwqgQ@mail.gmail.com>
I despair of getting an attachment through. Let's hope a link survives.
https://www.dropbox.com/s/2lfmrkp34j9z68n/Huffman.jpg?dl=0
The NYC Math Museum (MoMath) had/has an origami exhibit. Seems David
Huffman was interested in origami as well as compression.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://minnie.tuhs.org/pipermail/coff/attachments/20200129/2c0e96e5/attachment.html>
From dave at horsfall.org Fri Jan 31 06:25:59 2020
From: dave at horsfall.org (Dave Horsfall)
Date: Fri, 31 Jan 2020 07:25:59 +1100 (EST)
Subject: [COFF] The MOO problem and set-uid
In-Reply-To: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
Message-ID: <alpine.BSF.2.21.9999.2001310720340.15513@aneurin.horsfall.org>
Thanks, all, for the responses; it was driving me nuts! I know the game
as "cows and bulls" (or perhaps that's because I'm of British origin).
I like Dennis' observation: "On the other hand, suid these days seems to
be a fairly blunt and dangerous instrument". I've often believed that if
you thought you needed set-uid (esp. to root!) you can probably get away
with set-gid instead.
-- Dave
From bakul at bitblocks.com Fri Jan 31 07:51:03 2020
From: bakul at bitblocks.com (Bakul Shah)
Date: Thu, 30 Jan 2020 13:51:03 -0800
Subject: [COFF] The MOO problem and set-uid
In-Reply-To: <alpine.BSF.2.21.9999.2001310720340.15513@aneurin.horsfall.org>
References: <alpine.BSF.2.21.9999.2001290915500.9191@aneurin.horsfall.org>
<alpine.BSF.2.21.9999.2001310720340.15513@aneurin.horsfall.org>
Message-ID: <D013943C-153D-4658-B4DC-9374998714FF@bitblocks.com>
On Jan 30, 2020, at 12:25 PM, Dave Horsfall <dave at horsfall.org> wrote:
>
> Thanks, all, for the responses; it was driving me nuts! I know the game as "cows and bulls" (or perhaps that's because I'm of British origin).
>
> I like Dennis' observation: "On the other hand, suid these days seems to be a fairly blunt and dangerous instrument". I've often believed that if you thought you needed set-uid (esp. to root!) you can probably get away with set-gid instead.
Capabilities[1] (Dennis, Van Horn, 1966) would have solved the MOO problem.
And the CAP computer project had already started in Cambridge!
[1]
https://www.princeton.edu/~rblee/ELE572Papers/Fall04Readings/ProgramSemantics_DennisvanHorn.pdf
Re-reading this papers decades later it is interesting to see that
the modern object caps are basically not very different from the
original concept! Also interesting to see fork() here.