=> COFF
On 2022-Jan-30 10:07:15 -0800, Dan Stromberg <drsalists(a)gmail.com> wrote:
>On Sun, Jan 30, 2022 at 8:58 AM David Barto <david(a)kdbarto.org> wrote:
>
>> Yes, the UCSD P-code interpreter was ported to 4.1 BSD on the VAX and it
>> ran natively there. I used it on sdcsvax in my senior year (1980).
>
>This reminds me of a question I've had percolating in the back of my mind.
>
>Was USCD Pascal "compiled" or "interpreted" or both?
>
>And is Java? They both have a byte code interpreter.
A bit late to the party but my 2¢:
I think it's fairly clear that both UCSD Pascal and Java are compiled
- to binary machine code for a p-code machine or JVM respectively.
That's no different to compiling (eg) C to PDP-11 or amd64 binary
machine code.
As for how the machine code is executed:
* p-code was typically interpreted but (as mentioned elsewhere) there
were a number of hardware implementions.
* Java bytecode is often executed using a mixture of interpretation
and (JIT) compilation to the host's machine code. Again there are
a number of hardware implementations.
And looking the other way, all (AFAIK) PDP-11's were microcoded,
therefore you could equally well say that PDP-11 machine code is being
interpreted by the microcode on a "real" PDP-11. And, nowadays,
PDP-11 machine code is probably more commonly interpreted using
something like simh than being run on a hardware PDP-11.
Typical amd64 implementations are murkier - with machine code being
further converted ("compiled"?) into a variable number of micro-ops
that have their own caches and are then executed on the actual CPU.
(And, going back in time, the Transmeta Crusoe explicity did JIT
conversion from iA32 machine code to its own proprietary machine code).
--
Peter Jeremy
On Mon, Jan 31, 2022 at 10:17 AM Paul Winalski <paul.winalski(a)gmail.com>
wrote:
> On 1/30/22, Steve Nickolas <usotsuki(a)buric.co> wrote:
> > And I think I've heard the Infocom compilers' bytecode called "Z-code" (I
> > use this term too).
> That is correct. The Infocom games ran on an interpreter for an
> abstract machine called the Z-machine. Z-code is the Z-machine's
> instruction set. There is a freeware implementation out there called
> Frotz.
>
>
There's a reasonably functional Frotz implementation for TOPS-20, as it
happens. The ZIP interpreter was easier to port to 2.11BSD on the PDP-11.
https://github.com/athornton/tops20-frotz
Adam
"Reflections on Trusting Trust" plus the fact that no one has designed new
real computers at the gate level for at least 30 years, maybe longer--it's
done in an HDL of some kind, which is to say, software--means it's already
way, way too late.
I for one welcome our new non-biological overlords.
Adam
Hi all,
Given the recent (awesome) discussions about the history of *roff and TeX, I
thought I'd ask about where Brian Reid's Scribe system fits in with all this.
His thesis is available online here:
http://reports-archive.adm.cs.cmu.edu/anon/scan/CMU-CS-81-100.pdf, and in my
opinion is very interesting (also cites papers on roff and TeX). Does anybody
know if Scribe was ever used on Unix systems? Does it exist at all today?
Thanks :)
Josh
Moving to COFF.
John Labovitz wrote:
>>> The earliest known text-formatting software, TJ-2, was created by
>>> MIT-trained computer scientist Peter Samson in 1963.
>>
>> I see claimed predecessors are JUSTIFY and TJ-1. How do you feel
>> about those?
>
> I’m sure I looked for TJ-1 when I did this research — an obvious
> question, given the ‘2’ suffix — but didn’t find anything then. I’m
> not familiar with JUSTIFY.
Note, later there was also a TJ6 for the PDP-6, written by Richard
Greenblatt.
> Do you have links/info for those?
This one mentions TJ-1 near the end:
https://www.computerhistory.org/pdp-1/_media/pdf/DEC.pdp_1.1972.102650621.p…
The TJ-2 page on Wikipedia mentions JUSTIFY and links here:
http://www.ultimate.com/phil/pdp10/
Moving to COFF, but Brian Dear's "The Friendly Orange Glow", about Plato,
talks a lot about some of the cool stuff happening in the middle of the
country.
https://www.amazon.com/Friendly-Orange-Glow-Untold-Cyberculture/dp/11019736…
And later, of course, NCSA Mosaic.
On Wed, Jan 12, 2022 at 4:15 PM Greg 'groggy' Lehey <grog(a)lemis.com> wrote:
> On Tuesday, 11 January 2022 at 14:34:16 -0500, John Cowan wrote:
> > On Tue, Jan 11, 2022 at 1:37 PM Dan Cross <crossd(a)gmail.com> wrote:
> >> It seems like Unix is largely a child of the coasts.
> >
> > We can add the eastern coast of Australia, where the original
> > Wollongong group made the first V6 port to the Interdata 7/32 (not
> > to be confused with the Labs port to the 8/32).
>
> To be fair, in the case of Australia almost everybody is on the east
> coast, though we have had our share of FreeBSD core team members from
> the "west coast" (which is really only Perth).
>
> Greg
> --
> Sent from my desktop computer.
> Finger grog(a)lemis.com for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed. If your Microsoft mail program
> reports problems, please read http://lemis.com/broken-MUA.php
>
Taking this to COFF...
> On Jan 10, 2022, at 7:13 PM, Lyndon Nerenberg (VE7TFX/VE6BBM) <lyndon(a)orthanc.ca> wrote:
>
> Greg 'groggy' Lehey writes:
>
>> As long as man pages are formatted with ?roff, I don't see it going
>> away. I don't suppose many people use troff any more, but there are
>> enough of us, and as long as man pages stay the way they are, I don't
>> think we're in any danger.
>
> Well there is mandoc(1). But as time goes by they just seem to be
> re-implementing nroff. Of course that *must* be easier than just
> learning n/troff in the first place :-P
As someone who did a lot of a Ph.D. in the history of computing, and then went into IT because he liked eating protein sometimes:
The great secret is that NO ONE EVER READS THE LITERATURE.
We have now made all the mistakes at least four times:
Once for each of mainframes, minis, micros, and mobile.
You can be a rock star at any development or operations job, even if you are, like me, a Bear Of Little Brain, simply by having some idea of what was tried already to solve a problem like this, and why it didn't work.
Which you can get by actually stopping to read up about your problem before diving headfirst into coding up a solution for it.
If you happen to get stinking rich from this advice, you can buy me a bottle of whiskey sometime.
Adam
I think I've posted this question before, perhaps on TUHS, but I'll ask
again.
I have a PDP-11/03 with a Sykes Twin 8" Floppy Drive unit. It has it's own
controller card, so I'm not sure if it's RX01/RX02 compatible. Problem is,
I need a bootstrap program for it. I can't find a technical manual for it,
so I'm stuck.
I see the source for LSX has a driver for the Sykes, so I may be able to
install and mount it on MX, which I'm preparing with Noel's help for my
machine, without booting from it. I'm hoping that Heinz, or someone who had
a Sykes drive in that era still has the bootstrap code.
Paul
*Paul Riley*
Moving to COFF since while this is a UNIX issue its really attitude,
experience and perspective.
On Thu, Dec 30, 2021 at 8:01 PM Rob Pike <robpike(a)gmail.com> wrote:
> Grumpy hat on.
>
> Sometimes the Unix community suffers from the twin attitudes of a)
> believing if it can't be done perfectly, any improvement shouldn't be
> attempted at all and b) it's already done as well as is possible anyway.
>
> I disagree with both of these positions, obviously, but have given up
> pushing against them.
>
> We're in the 6th decade of Unix and we still suffer from unintended,
> fixable consequences of decisions made long long ago.
>
> Grumpy hat off.
>
> -rob
>
While I often agree with you and am a huge fan of your work both written
and programming, I am going to take a different position:
I am very much into researching different solutions and love exploring them
and seeing how to apply the lessons, but *just because we can change a
change*, *does not always mean we should*. IMOI: *Economics has to play
into equation*.
I offer the IPv4 to IPv6 fiasco as an example of a change because we could
(and we thought it would help - hey I did in the early 1990s), but it
failed for economic reasons. In the end, any real change has to take into
account some level of economics.
The examples of the differences in the shell is actually a different issue
-- that was territorial and not economics -- each vendor adding stuff that
helped them (and drove IVS/end users of multiple platforms crazy). The
reality with SunOS sh vs Ultrix sh vs HP-UX sh vs System V (att sh) was yet
another similar but different -- every manufacturer messed with a V7
derivative sh was a little different -- including AT&T, Korn et al. For
that matter you (Rob) created a new syntax command with Plan9 [although you
did not try to be and never claimed to be V7 compatible -- to your point
you break things where you thought it matters and as a researcher I accept
that]. But because all the manufacturers were a little different, it was
exactly why IEEE said -- wait a minute -- let's define a base syntax which
will work everywhere and it is something we can all agree and if we all
support it -- great. We did that, and we call that POSIX (and because it
was designed by compromise and committee - like a camel it has some humps).
*But that does mean compromise -- some agreed 'sh' basics needs to keep the
base level.*
The problem Ted and Larry describes is real ... research *vs.* production.
So it begs the question, at what time does it make it sensible/ (worth
it/economically viable) to move on?
Apple famously breaks things and it drives me bonkers because many (most I
would suggest) of those changes are hardly worth it -- be it my iPhone or
my Mac. I just want to use the darned thing BTW: Last week, the clowns at
Telsa just rolled out a new UI for my Model S --- ugh -- because they could
(now I'm fumbling trying deal with the climate system or the radio -- it
would not do bad if they had rolled out a the new UI on a simulator for my
iPad so I could at least get used to it -- but I'm having to learn it live
-- what a PITA -- that really makes me grumpy).
What I ask for this august body to consider is that before we start looking
at these changes is to ask what we are really getting in return when a new
implementation breaks something that worked before. *e.g.* I did not think
systemd bought end users much value able, must like IPv6 in practice, it
was thought to solve many problems, but did not buy that much and has
caused (continues to cause) many more.
In biolog every so often we have an "ice age" and kill a few things off and
get to start over. That rarely happens in technology, except when a real
Christianen style disruption takes place -- which is based on economics --
a new market values the new idea and the old market dies off. I believe
that from the batch/mainframe 1960s/early 70s world, Unix was just that --
but we got to start over because the economics of 'open systems' and the
>>IP<< being 'freely available' [which compared to VMS and other really
proprietary systems] did kill them off. I also think that the economics
of completely free (Linux) ended up killing the custom Unix diversions.
Frankly, if (at the beginning) Plan9 has been a tad easier/cheaper/more
economical for >>everyone<< in the community obtain (unlike original Unix
release time, Plan9 was not the same rules because AT&T was under different
rules and HW cost rules had changed things), it >>might<< have been the
strong strain that killed off the old. If IPv6 has been (in practice)
cheaper to use than IPv4 [which is what I personally thought the ISP would
do with it - since it had been designed to help them] and not made as a
premium feature (i.e they had made it economically to change), it might
have killed of IPv4.
Look at 7 decades of Programming Language design, just being 'better' is
not good enough. As I have said here and many other places, the reality is
that Fortran still pays the salary of people like me in the HPC area [and I
don't see Julia or for that matter, my own company's pretty flower - Data
Parallel C++ making inroads soon]. It's possible that Rust as a system
programming language >>might<< prove economical to replace C. I personally
hope Go makes the inroads to replace C++ in user space. But for either to
do that, there has to be an economical reason - no brainer style for
management.
What got us here was a discussion of the original implementation of
directory files, WRT links and how paths are traversed. The basic
argument comes from issues with how and when objects are named. Rob, I
agree with you, that just because UNIX (or any other system) used a scheme
previously does not make the end-all. And I do believe that rethinking
some of the choices made 5-6 decades ago is in order. But I ask the
analysis of the new verse the old takes into account, how to mitigate the
damage done. If its economics prove valuable, the evolution to using it
will allow a stronger strain to take over, but just because something new
vs. the old, does not make it valuable.
Respectfully ....
Happy new year everyone and hopefully 2022 proves a positive time for all
of you.
Clem
Moving to COFF, perhaps prematurely, but...
It feels weird to be a Unix native (which I consider myself: got my first
taste of Irix and SVR3 in 1989, went to college where it was a Sun-mostly
environment, started running Linux on my own machines in 1992 and never
stopped). (For purposes of this discussion, of course Linux is Unix.)
It feels weird the same way it was weird when I was working for Express
Scripts, and then ESRX bought Medco, and all of a sudden we were the 500-lb
Gorilla. That's why I left: we (particularly my little group) had been
doing some fairly cool and innovative stuff, and after that deal closed, we
switched over entirely to playing defense, and it got really boring really
fast. My biggest win after that was showing that Pega ran perfectly fine
on Tomcat, which caused IBM to say something like "oh did we say $5 million
a year to license Websphere App Server? Uh...we meant $50K." So I saved
them a lot of money but it sucked to watch several months' work flushed
down the toilet, even though the savings to the company was many times my
salary for those months.
But the weird part is similar: Unix won. Windows *lost*. Sure, corporate
desktops still mostly run Windows, and those people who use it mostly hate
it. But people who like using computers...use Macs (or, sure, Linux, and
then there are those weirdos like me who enjoy running all sorts of
ancient-or-niche-systems, many of which are Unix). And all the people who
don't care do computing tasks on their phones, which are running either
Android--a Unix--or iOS--also a Unix. It's ubiquitous. It's the air you
breathe. It's no longer strange to be a Unix user, it means you use a
21st-century electronic device.
And, sure, it's got its warts, but it's still basically the least-worst
thing out there. And it continues to flabbergast me that a typesetting
system designed to run on single-processor 16-bit machines has, basically,
conquered the world.
Adam
P.S. It's also about time, he said with a sigh of relief, having been an
OS/2 partisan, and a BeOS partisan, back in the day. Nice to back a
winning horse for once.
On Thu, Dec 30, 2021 at 6:46 PM Bakul Shah <bakul(a)iitbombay.org> wrote:
> ?
>
> I was just explaining Ts'o's point, not agreeing with it. The first
> example I
> gave works just fine on plan9 (unlike on unix). And since it doesn't allow
> renames, the scenario T'so outlines can't happen there! But we were
> discussing Unix here.
>
> As for symlinks, if we have to have them, storing a path actually makes
> their
> use less surprising.
>
> We're in the 6th decade of Unix and we still suffer from unintended,
> fixable consequences of decisions made long long ago.
>
>
> No argument here. Perhaps you can suggest a path for fixing?
>
> On Dec 30, 2021, at 5:00 PM, Rob Pike <robpike(a)gmail.com> wrote:
>
> Grumpy hat on.
>
> Sometimes the Unix community suffers from the twin attitudes of a)
> believing if it can't be done perfectly, any improvement shouldn't be
> attempted at all and b) it's already done as well as is possible anyway.
>
> I disagree with both of these positions, obviously, but have given up
> pushing against them.
>
> We're in the 6th decade of Unix and we still suffer from unintended,
> fixable consequences of decisions made long long ago.
>
> Grumpy hat off.
>
> -rob
>
>
> On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul(a)iitbombay.org> wrote:
>
>> On Dec 30, 2021, at 2:31 PM, Dan Cross <crossd(a)gmail.com> wrote:
>> >
>> > On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
>> >>
>> >> The other problem with storing the path as a string is that if
>> >> higher-level directories get renamed, the path would become
>> >> invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
>> >> renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string would
>> >> become invalidated.
>> >
>> > Why? Presumably as you traversed the filesystem, you'd cache, (path
>> > component, inode) pairs and keep a ref on the inode. For any given
>> > file, including $CWD, you'd know it's pathname from the root as you
>> > accessed it, but if it got renamed, it wouldn't matter because you'd
>> > have cached a reference to the inode.
>>
>> Without the ".." entry you can't map a dir inode back to a path.
>> Note that something similar can happen even today:
>>
>> $ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
>> cd: no such file or directory: ..
>>
>> $ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
>> ls: ../b: No such file or directory
>>
>> You can't protect the user from every such case. Storing a path
>> instead of the cwd inode simply changes the symptoms.
>>
>>
>>
>