> From: Clem Cole
> I'm thrilled to see the 11 kept alive.
Ditto. The most elegant archtecture ever, IMO.
> I was under the impression ??Ken?? had created them for B
> independently (which, of course, was first on the PDP-7).
"The Development of the C Language", by Dennis M. Ritchie:
https://www.bell-labs.com/usr/dmr/www/chist.html
says:
The PDP-7, however, did have a few `auto-increment' memory cells, with the
property that an indirect memory reference through them incremented the cell.
This feature probably suggested such operators to Thompson; the
generalization to make them both prefix and postfix was his own. Indeed,
the auto-increment cells were not used directly in implementation of the
operators, and a stronger motivation for the innovation was probably his
observation that the translation of ++x was smaller than that of x=x+1.
Note the "probably"; unless Ken remembers, and says something, that's
probably the best we are going to get.
> I did not think the PDP-7 ISA includes addressing modes in the same
> manner as the 11. .. I thought PDP-7 is a very simple instruction (and
> small) with an AC, Link/Indirection and a PC - it reminded me of the
> PDP-8 more than anything else
The PDP-4, -7 and -9 are all the same architecture (very similar to the
PDP-1, but simplified a bit), differing only in implementation. (Most PDP-7
code will run on a -9, un-modified.) Basic instructions look like:
Instructions had a 4-bit opcode ('000'-'054'), 1 bit of indirect, and 13
bits of address. It was a load-store architecture, with a single accumulator.
So, yes, similar to an -8. There are other opcodes for non-memory operations
('074' opcode), and I/O ('070'), using bits in the 'address' field. ('060'
opcodes were for the optional EAE.) All of the -4/-7/-9 had the
'auto-increment on locations 010-017' when indirecting through them' feature.
Bitsavers has fairly complete docs on them all:
http://www.bitsavers.org/pdf/dec/pdp4/http://www.bitsavers.org/pdf/dec/pdp7/http://www.bitsavers.org/pdf/dec/pdp9/
Noel
> From: "Nelson H. F. Beebe"
> there is a nice compact history of the PDP-11 and early Unix at this
> new article:
Not a bad artcle, but it had a number of minor errors, which I found irritating.
They should have gotten an expert to proof it.
Here are some:
registers could access any other register - as well as memory or direct
data - using one of the six different addressing modes
I think 'instruction' may have been meant for the first "register"; as
written it makes on sense. (Unlike the PDP-10, in the PDP-11, a register
can't address another register.) Oh, and there are eight addressing modes.
use of labels instead of hard-coded addresses makes it easier to
program and makes the code relocatable in memory
I'm not sure whether the writer knows the difference between 'PC-relative
addressing' (a PDP-11 feature; code that will run at any address, without
_any_ changes to the binary) and 'relocatable binary (which uses labels, as he
describes). - but is not PDP-11 specific.
The program counter can be accessed like any of the other registers ... The
program counter is intended to support jump, branching, and other control
flow instructions.
Uh, no. It's not clear _exactly_ what was meant here, but... having the PC as
a general register is for PC-relative addressing of operands, immediate data,
and absolute addressing of operands. Jumps, branches, etc don't use the fact
that the PC is a general register.
These are the key advantages of assembly programming over high-level
languages - assembler code always runs faster and uses less memory.
Not really, with modern compilers.
The number above represents -2.
A commenter caught this one.
Just use a $ to represent a decimal number
In UNIX assembler, "$" means 'immediate data'; a trailing
"." means decimal.
And a tip of the hatly hat for getting this:
Although the ++ and - operators in C are equivalents of DEC and INC
instructions, they were inspired by an addressing mode in the PDP-7.
right.
Noel
Although the story is well known to members of this list, there is a nice
compact history of the PDP-11 and early Unix at this new article:
A brief tour of the PDP-11, the most influential minicomputer of all time
https://arstechnica.com/gadgets/2022/03/a-brief-tour-of-the-pdp-11-the-most…
It describes PDP-11 assembly language, and shows the booting of a Unix
system on a simh instance. It also includes the famous picture of
Dennis and Ken at a PDP-11 console, and concludes with a link to an
online text of a book about PDP-11 assembly language programming.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
I am reading some UNIX text processing books and am interested in the
lineage of Documenter's Workbench.
I see documentation of 1.0 (i.e
https://archive.org/details/sysv-dwb/page/n5/mode/2up)
I see a copy of 2.0 for 3B2 (i.e.
https://archives.loomcom.com/3b2/software/Documenters_Workbench/)
>From there things get a little less clear, it seems like we jump to
3.2 with SysVR3.2?
Then there is a 3.3 version https://github.com/n-t-roff/DWB3.3
One of my books from the late 80s references 3.4 available as a source
code purchase independent of UNIX.
Then it appears SGI might have had a 4.x strain? (i.e.
https://archive.org/details/sgi_Documenters_Workbench_4.1.3)
Heirloom is derived from OpenSolaris which is derived from?
Can anyone firm this lineage up a bit; and is 4.x an SGI thing or what
(I extracted the image, the relnotes inside might as well not exist).
Regards,
Kevin
> On Mar 12, 2022, at 2:02 PM, Rob Pike <r(a)golang.org> wrote:
>
> Indeed. Be careful about the code Numerical Recipes if you are doing
> important numerical work.
> For simple stuff it's fine, of course, but floating point is a
> minefield that requires expert navigation.
>
> -rob
That's the seductive trap of floating-point numbers, isn't it? They invite us to think about them as if they were the real numbers, but they are very, very much *not* the real numbers. And yet, most of the time, for most applications, if you treat them as if they were, you get plausible results.
Adam
Hello,
I'm trying to understand a quirk in 32-bit x86 code generation conventions:
on Linux, when returning a structure from a function by value:
struct S {
int i, j;
};
struct S f(int x)
{
return (struct S){x, sizeof(void*)};
}
the caller reserves space for the returned structure and passes a pointer
to that space as an 'invisible' extra argument, which is prepended to
the argument list; the callee returns this pointer (although the caller
knows it anyway); it's as if the function is transformed to
struct S *f(struct S *ret, int x)
{
ret->i = x;
ret->j = sizeof(void*);
return ret;
}
with one essential difference: the function 'f' itself is responsible for
popping the extra argument off the stack (the 'x' argument is popped by
its caller).
This necessitates using the return-with-immediate ('ret 4') instruction
instead of the normal 'ret'; this is the only instance where this variant of
the 'ret' instruction is used in code generation for C programs on Linux
normally.
I wonder how this exception came to be.
Early versions of GCC (e.g. gcc-1.27) did not implement this convention, i.e.
the caller was responsible for popping the invisible pointer similar to the
normal arguments. The "callee-pops" variant was implemented later for
"compatibility with other compilers", and the option that controls this is
called -fpcc-struct-return, which also disables returning small structures in
registers (in the example above GCC would return the value in EDX:EAX register
pair).
Operating systems differ on following this convention. For example, FreeBSD
and OpenBSD do not, and neither does Windows.
Looking at 386BSD tree in unix-history-repo, I see that it used GCC, not PCC.
Where can I look at the history of x86 code generation development in PCC?
Do I understand correctly that i386 code generation in PCC evolved in parallel
with GCC, and at some point GCC was convinced to adopt the (less efficient)
PCC calling convention by default?
Did PCC prefer to do this stack adjustment for the invisible pointer on the
callee side for some other platform, and the behavior was merely carried over
to the i386 port?
Thank you.
Alexander
> The Documenter's Workbench is sort of the unsung hero
> of Unix. It is why Unix exists, Unix was done to write patents and
> troff and the Documenter's Workbench was all about that.
My response along the following lines seems to have gone astray.
The prime reason for Unix was the desire of Ken, Dennis, and Joe
Ossanna to have a pleasant environment for software development.
The fig leaf that got the nod from Multics-burned management was
that an early use would be to develop a "stand-alone" word-processing
system for use in typing pools and secretarial offices. Perhaps they
had in mind "dedicated", as distinct from "stand-alone"; that's
what eventuated in various cases, most notably in the legal/patent
department and in the AT&T CEO's office.
Both those systems were targets of opportunity, not foreseen from the
start. When Unix was up and running on the PDP-11, Joe got wind of
the legal department having installed a commercial word processor.
He went to pitch Unix as an alternative and clinched a trial by
promising to make roff able to number lines by tomorrow in order to
fulfill a patent-office requirement that the commercial system did
not support.
Modems were installed so legal-department secretaries could try the
Research machine. They liked it and Joe's superb customer service.
Soon the legal department got a system of their own. Joe went on to
create nroff and troff. Document preparation became a widespread use
of Unix, but no stand-alone word-processing system was ever undertaken.
Doug
Decades ago (mid 1993) I produced a CD-ROM with free software for
Novell's UnixWare entitled "Applications for UnixWare". This was at
Novell's request, and they distributed the CDs at trade shows.
There's nothing very special in the CD, but I recently received a
request for it, so I put it up with a minimal description at
http://www.lemis.com/grog/Software/Applications-for-UnixWare.php
Feel free to copy it (with attribution).
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
All, I've just placed this document at
https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru…
Many thanks to Doug for passing it on!
Cheers, Warren
----- Forwarded message from Douglas McIlroy -----
Warren,
Someone asked if Brenda Baker's original technical memorandum about
struct is available. I scanned my copy and passed it on, secure in my
belief that the Labs won't care since it is essentially the same as
her journal publication.
For the memo to be genuinely available, I'd like to send it to TUHS.
With that in mind I redacted information about corporate organization
and distribution channels. However the memo still bears the AT&T logo
and the words "not for publication".
Doug
----- End forwarded message -----
Thanks to Doug and Warren for getting Brenda Baker's memo on struct
online at
https://www.tuhs.org/Archive/Documentation/TechReports/Baker_Struct/bsbstru…
She later published a formal article about that work in
An Algorithm for Structuring Flowgraphs
Journal of the Association for Computing Machinery 24(1) 98--120 January 1977
https://doi.org/10.1145/321992.321999
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
