3 Jan
2016
3 Jan
'16
11:35 p.m.
I just re-found a quote about Unix processes that I'd "lost". It's by
Steve Johnson:
Dennis Ritchie encouraged modularity by telling all and sundry that
function calls were really, really cheap in C. Everybody started
writing small functions and modularizing. Years later we found out
that function calls were still expensive on the PDP-11, and VAX code
was often spending 50% of its time in the CALLS instruction. Dennis
had lied to us! But it was too late; we were all hooked...
http://www.catb.org/esr/writings/taoup/html/modularitychapter.html
Steve, can you recollect when you said this, was it just a quote for
Eric's book or did it come from elsewhere?
Does anybodu have a measure of the expense of function calls under Unix
on either platform?
Cheers, Warren
3 Jan
3 Jan
11:53 p.m.
On 3 Jan 2016, at 23:35, Warren Toomey
<wkt(a)tuhs.org> wrote:
Does anybodu have a measure of the expense of function calls under Unix
on either platform?
I don't have the reference to hand, but one of the things Lisp implementations
(probably Franz Lisp in particular) did on the VAX was not to use CALLS: they could do
this because they didn't need to interoperate with C except at known points (where
they would use the C calling conventions). This change made a really significant
difference to function call performance and meant that on call-heavy code Lisp was often
very competitive with C.
I can look up the reference (or, really, ask someone who remembers).
The VAX architecture and its performance horrors must have killed DEC, I guess.
4 Jan
4 Jan
12:01 a.m.
Tim Bradshaw scripsit:
The VAX architecture and its performance horrors must
have killed DEC,
I guess.
Like most things, it was overdetermined: the Rainbow and the lack of
insight it represented was another major cause.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
4:40 a.m.
I guess I experienced things a little differently: computer science basis notwithstanding,
the VAX was hugely successful for DEC.
aps.
On Jan 3, 2016, at 4:01 PM, John Cowan
<cowan(a)mercury.ccil.org> wrote:
Tim Bradshaw scripsit:
The VAX architecture and its performance horrors
must have killed DEC,
I guess.
Like most things, it was overdetermined: the Rainbow and the lack of
insight it represented was another major cause.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
The native charset of SMS messages supports English, French, mainland
Scandinavian languages, German, Italian, Spanish with no accents, and
GREEK SHOUTING. Everything else has to be Unicode, which means you get
only 70 16-bit characters in a text instead of 160 7-bit characters.
8:52 a.m.
On 4 Jan 2016, at 04:40, Armando Stettner <aps(a)ieee.org> wrote:
I guess I experienced things a little differently:
computer science basis notwithstanding, the VAX was hugely successful for DEC.
I think it was, too. What I meant, though, was that, although x86 demonstrates that
it's possible to make almost anything fast by the application of sufficient money,
the VAX was something which was expensive to keep performance-competitive, especially in
the era when RISC could make really easy wins, and the cost of doing that hurt DEC pretty
badly, I would expect (and made VAXes increasingly expensive compared to the competition,
which I remember them being in the late 80s). And I guess Alpha was too late.
--tim
5:29 p.m.
On Mon, Jan 04, 2016 at 08:52:51AM +0000, Tim Bradshaw wrote:
On 4 Jan 2016, at 04:40, Armando Stettner
<aps(a)ieee.org> wrote:
Yeah, the 750 was OK [*], the 780 was nice, the 8600 (which UW-Madison
named "speedy.rsch.wisc.edu", such a bad name) was expensive. They threw
a lot of hardware at the perf problem and it seems, to me at least, they
made a pretty good case for the RISC tradeoffs. But those tradeoffs made
sense when transistors were expensive; these days x86 has shown you can
get some sweet perf out of that CISCy design (though I believe it's sort
of a RISC under the covers).
And as for Alpha, I never warmed up to it. It was never fast for the
workloads I cared about (build, test, file serving, integer stuff).
To me, it was over hyped and it under delivered. Too bad, I liked
DEC as a company.
[*] the 750 at the UW CS department was where they kept the BSD sources,
it was called slovax. It was slow but I had so much fun reading that
code that I've always had a machine named slovax ever since, the current
one is mcvoy.com.
I guess I experienced things a little
differently: computer science basis notwithstanding, the VAX was hugely successful for
DEC.
I think it was, too. What I meant, though, was that, although x86
demonstrates that it's possible to make almost anything fast by the
application of sufficient money, the VAX was something which was expensive
to keep performance-competitive, especially in the era when RISC could
make really easy wins, and the cost of doing that hurt DEC pretty badly,
I would expect (and made VAXes increasingly expensive compared to the
competition, which I remember them being in the late 80s). And I guess
Alpha was too late. 
5 Jan
5 Jan
2 a.m.
Just never figured out how to make good use of the MARK instruction on the PDP-11.
4:46 p.m.
Clem Cole scripsit:
On Mon, Jan 4, 2016 at 9:00 PM, Ronald Natalie
<ron(a)ronnatalie.com> wrote:
My guess would be that it was intended to support the antiquated Fortran
feature of "multiple returns", whereby a caller could pass one or more
labels (defined in the caller) to the callee, which could then choose to
return directly to one of them rather than through the return address.
In gcc this is implemented by wrapping the call in a switch which
does a (local) goto based on the integer returned by the callee.
(Only subroutines, i.e. subprograms that do not return a user-visible
value, supported multiple returns.)
A PDP-11 Fortran compiler could have followed such a subroutine call by
a series of branch instructions and had the callee use MARK rather than
RTS to return to the correct point in the jump table.
This doesn't explain why some sources of instruction-set information
say that MARK "facilitates stack clean-up procedures", though.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
How they ever reached any conclusion at all is starkly unknowable
to the human mind. --"Backstage Lensman", Randall Garrett
Just never figured out how to make good use of
the MARK instruction on the
PDP-11.
If I understand it correctly, few if anyone did. 
5:33 p.m.
On 05/01/2016 18:46, John Cowan wrote:
Clem Cole scripsit:
Digital's handbook presents a reasonable (if unusual for Unix) calling
convention that uses MARK. It terms the convention "the standard PDP-11
subroutine return convention".
https://pdos.csail.mit.edu/6.828/2005/readings/pdp11-40.pdf#page=107
This convention pushes a tailored MARK instruction onto the stack, and
then has the called routine return to the address of the pushed MARK
instruction. MARK will in turn clean up the stack and restore R5. If I
understand things correctly, this saves one instruction over doing the
same things through other explicit instructions.
Interestingly, many years before the invention of stack smashing
attacks, we had a calling convention that was based on executing code
placed on the stack.
On Mon, Jan 4, 2016 at 9:00 PM, Ronald Natalie
<ron(a)ronnatalie.com> wrote:
My guess would be that it was intended to support the antiquated Fortran
feature of "multiple returns" Just never figured out how to make good use of
the MARK instruction on the
PDP-11.
If I understand it correctly, few if anyone did. 
5:42 p.m.
On Tue, Jan 5, 2016 at 11:46 AM, John Cowan <cowan(a)mercury.ccil.org> wrote:
A PDP-11 Fortran compiler could have followed such a
subroutine call by
a series of branch instructions and had the callee use MARK rather than
RTS to return to the correct point in the jump table.
Could be - I was not there for that one but, I'll have to try to ask one or
two of the designers of the the 11 FTN compiler back end when I see them
next who was. Rich or Dave might know/remember. That said, some of the
folks on the simh mailing list might also remember like Tim or Bob.
That said, IIRC the PDP-11 on chip did not support it, so I suspect the FTN
compiler did not use it. I also know that in the past, when we had talked
about some of the silly instructions that were created in different ISPs
during lunch conversations, I have specific memories of some of the
compiler folks saying they could never figure out PDP-11's MARK either -
hence my comment about few did know how to put it to good use.
5:28 p.m.
On Jan 5, 2016, at 10:13 AM, Clem Cole
<clemc(a)ccc.com> wrote:
If I understand it correctly, few if anyone did.
Clem
I remember going to the T11 (PDP-11 on a single chip) announcement and having them say the
complete instruction set was supported with the exception of MARK.
There was me and one other geek going “What? No MARK Instruction?” in the back of the
hall.
5:43 p.m.
On Tue, Jan 5, 2016 at 12:28 PM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
I remember going to the T11 (PDP-11 on a single chip)
announcement and
having them say the complete instruction set was supported with the
exception of MARK.
right... which is why I don't think FTN use it, or the HW folks would have
been forced to put it in.
Clem
5:46 p.m.
No, to my knowledge NO compiler I ever came across (I worked on the dark side DOS BATCH,
RT-11, RSX-11, and RSTS-11 in various languages though primarily MACRO-11 and FORTRAN)
ever used this linkage. Certainly, none of the UNIX products did. It was goofy. We
played around with it and it just didn’t do anything you couldn’t do better with JSR/RET
and some clever stack manipulation with MOV instructions.
On Jan 5, 2016, at 12:43 PM, Clem Cole
<clemc(a)ccc.com> wrote:
On Tue, Jan 5, 2016 at 12:28 PM, Ronald Natalie <ron(a)ronnatalie.com
<mailto:ron@ronnatalie.com>> wrote:
I remember going to the T11 (PDP-11 on a single chip) announcement and having them say
the complete instruction set was supported with the exception of MARK.
right... which is why I don't think FTN use it, or the HW folks would have been
forced to put it in.
Clem
6:03 p.m.
Back in the early days of my career, I saw MARK used once in
MACRO-11 to implement a switch statement. It was horrific and super
long compared to the code that replaced it a few months later. It was a
horrible abuse of the instruction, and the person who wrote the code
(not me) was just learning PDP-11 ropes at the time. The replacement
code was also faster. I doubt I'd ever have noticed if this code didn't
wind up in the hot path and attract the attention of the senior engineer
on the project. He was so horrified, he called us all together to go over
what the instruction actually did, and why it was such a bad idea.
Warner
On Tue, Jan 5, 2016 at 10:46 AM, Ronald Natalie <ron(a)ronnatalie.com> wrote:
No, to my knowledge NO compiler I ever came across (I
worked on the dark
side DOS BATCH, RT-11, RSX-11, and RSTS-11 in various languages though
primarily MACRO-11 and FORTRAN) ever used this linkage. Certainly, none
of the UNIX products did. It was goofy. We played around with it and
it just didn’t do anything you couldn’t do better with JSR/RET and some
clever stack manipulation with MOV instructions.
On Jan 5, 2016, at 12:43 PM, Clem Cole <clemc(a)ccc.com> wrote:
On Tue, Jan 5, 2016 at 12:28 PM, Ronald Natalie <ron(a)ronnatalie.com>
wrote:
I remember going to the T11 (PDP-11 on a single
chip) announcement and
having them say the complete instruction set was supported with the
exception of MARK.
right... which is why I don't think FTN use it, or the HW folks would
have been forced to put it in.
Clem
6:24 p.m.
Ah, this brings back memories. We had this MACRO-11 concept called “threaded code” (not
threads in the multiprocessing sense). Essentially we had very small code fragments
that were loaded into a table and we’d run them to process data with very light JSR/RET
linkage (minimal register saves).
Getting back to Richie’s idea of lightweight functions, it indeed is a more maintainable
style and perhaps ahead of it’s time when modern highly optimized inlining compilers came
around it made it efficient without the programmer needing to wrap his head around it too
much.
On Jan 5, 2016, at 1:03 PM, Warner Losh
<imp(a)bsdimp.com> wrote:
Back in the early days of my career, I saw MARK used once in
MACRO-11 to implement a switch statement.
8:26 p.m.
Ah, this brings back memories. We had this MACRO-11
concept called
âthreaded codeâ (not threads in the multiprocessing sense).
Essentially we had very small code fragments that were loaded into a table
and weâd run them to process data with very light JSR/RET linkage
(minimal register saves).
Getting back to Richieâs idea of lightweight functions, it indeed is a
more maintainable style and perhaps ahead of itâs time when modern
highly optimized inlining compilers came around it made it efficient
without the programmer needing to wrap his head around it too much.
It brought back memories for me, too. At Ardent, we had a 4-processor
system with each processor a vector processor. We wanted to be able to go
between parallel and serial very quickly, and the key to achieving this
was to have all 4 threads share the stack. So in the parallel sections,
all function calls had to be lightweight (only JSR/RET) and keep their
paws off some of the registers (including the stack pointer). It worked
beautifully, giving us a 3.99 times speedup with 4 processors when we were
in its sweet spot.
8:49 p.m.
Ronald Natalie scripsit:
Ah, this brings back memories. We had this MACRO-11
concept called
“threaded code” (not threads in the multiprocessing sense).
Essentially we had very small code fragments that were loaded into
a table and we’d run them to process data with very light JSR/RET
linkage (minimal register saves).
I wrote an interpreter for a Forth-ish language in Macro-11 for RT-11.
The core dispatch loop was just two instructions:
JSR PC, @(R5)+
BR .-1
When entered with R5 equal to the beginning of a series of addresses of
routines to be entered, this invoked the routines at the addresses in turn.
If the routine was in machine language, it terminated with RTS PC
(shorter than JMP-ing back to the dispatch loop). If it was itself
threaded code, it began with JSR R5,DISPATCH, which pushed R5 on the
stack and loaded it up with the next instruction, and terminated with
the address of an POP R5 instruction conveniently placed just before
the dispatch loop.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
You annoy me, Rattray! You disgust me! You irritate me unspeakably!
Thank Heaven, I am a man of equable temper, or I should scarcely be able
to contain myself before your mocking visage. --Stalky imitating Macrea
11:55 p.m.
The only thing we really used on RSTS was Basic Plus so I wouldn’t know, but I spent a lot
of time making cross calls between MACRO-11 and FORTRAN on the RSX-11M and there was no
MARK-based linkage in anything I saw. I had the kind of odd misfortunate to spend one
summer in college writing a database system in Fortran and Macro-11 on RT and when I
graduated the company saw that and set me down to work on FORTRAN/MACRO-based database on
their two processor RSX-11M system.
On Jan 5, 2016, at 6:24 PM, Dave Horsfall
<dave(a)horsfall.org> wrote:
On Mon, 4 Jan 2016, Ronald Natalie wrote:
Just never figured out how to make good use of
the MARK instruction on
the PDP-11.
RSX-11 probably used it, though, as could've RSTS...
4 Jan
4 Jan
midnight
Warren Toomey scripsit:
VAX code was often spending 50% of its time in
the CALLS
instruction.
From what I understand, the use of CALLS was abandoned
on the VAX
at some point in favor of a cheaper calling convention.
--
John Cowan http://www.ccil.org/~cowan cowan(a)ccil.org
Where the wombat has walked, it will inevitably walk again.
(even through brick walls!)
12:42 a.m.
Well, I certainly said this on several occasions, and the fact that it is
recorded more or less exactly as I remember saying it suggests that I may
have even written it somewhere, but if so, I don't recall where...
As part of the PCC work, I wrote a technical report on how to design a C
calling sequence, but that was before the VAX. Early calling sequences
had both a stack pointer and a frame pointer, but for most machines it
was possible to get by with just one, so calling sequences got better as
time went on. Also, RISC machines with many more registers than the
PDP-11 also led to more efficient calls by putting some arguments in
registers. Later standardizations like varargs were painful on some
architectures (especially those which had different registers for pointers
and integers).
The CALLS instruction was indeed a pig -- a space-time tradeoff in the
wrong direction! For languages like FORTRAN it might have been justified,
but for C it was awful. It is my memory too that CALLS was abandoned,
perhaps first at UCB. But I actually had little hands-on experience with
the VAX C compiler...
Steve
I just re-found a quote about Unix processes that
I'd "lost". It's by
Steve Johnson:
Dennis Ritchie encouraged modularity by telling all and sundry that
function calls were really, really cheap in C. Everybody started
writing small functions and modularizing. Years later we found out
that function calls were still expensive on the PDP-11, and VAX code
was often spending 50% of its time in the CALLS instruction. Dennis
had lied to us! But it was too late; we were all hooked...
http://www.catb.org/esr/writings/taoup/html/modularitychapter.html
Steve, can you recollect when you said this, was it just a quote for
Eric's book or did it come from elsewhere?
Does anybodu have a measure of the expense of function calls under Unix
on either platform?
Cheers, Warren
11:35 a.m.
scj(a)yaccman.com <scj(a)yaccman.com> wrote:
As part of the PCC work, I wrote a technical report on how to design a C
calling sequence, but that was before the VAX. Early calling sequences
had both a stack pointer and a frame pointer, but for most machines it
was possible to get by with just one, so calling sequences got better as
time went on. Also, RISC machines with many more registers than the
PDP-11 also led to more efficient calls by putting some arguments in
registers. Later standardizations like varargs were painful on some
architectures (especially those which had different registers for pointers
and integers).
I had a look for your technical report online but my searches failed me.
Do you have a link to a copy?
Doesn't alloca() get interesting if you have a stack pointer but no frame
pointer? :-)
http://minnie.tuhs.org/cgi-bin/utree.pl?file=4BSD/usr/src/libc/sys/alloca.s
Nowadays it's usually implemented as a builtin, and given that the
compiler ought to be able to cope in most cases, but if you alloca() a
variable amount things soon get too difficult...
Tony.
--
f.anthony.n.finch <dot(a)dotat.at> http://dotat.at/
Northeast Viking, North Utsire: Southeasterly 5 to 7, occasionally gale 8 in
south. Rough or very rough, occasionally moderate later. Fair. Good.
3036
days inactive
3038
days old
23 comments
12 participants
participants (12)
-
Armando Stettner -
Clem Cole -
Dave Horsfall -
Diomidis Spinellis -
John Cowan -
Larry McVoy -
Ronald Natalie -
scj＠yaccman.com -
Tim Bradshaw -
Tony Finch -
Warner Losh -
Warren Toomey