List of Archived Posts

2003 Newsgroup Postings (04/08 - 05/01)

Alpha performance, why?

Share in DC: was somethin' else

Share in DC: was somethin' else

Disk capacity and backup solutions

saving country music

Any DEC 340 Display System Doco ?

Oldest system to run a web browser?

Any DEC 340 Display System Doco ?

Redhat 9

Determining Key Exchange Frequency?

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

Page Table - per OS/Process

Page Table - per OS/Process

Page Table - per OS/Process

Page Table - per OS/Process

Disk capacity and backup solutions

Can someone clarify, X509 spoofing?

Can someone clarify, X509 spoofing?

Multiple layers of virtual address translation

Multiple layers of virtual address translation

price ov IBM virtual address box??

price ov IBM virtual address box??

303x, idals, dat, disk head settle, and other rambling folklore

price ov IBM virtual address box??

UltraSPARC-IIIi

303x, idals, dat, disk head settle, and other rambling folklore

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

SYSPROF and the 190 disk

Any DEC 340 Display System Doco ?

Lisp Machines

One Processor is bad?

Lisp Machines

One Processor is bad?

price ov IBM virtual address box??

Lisp Machines

Mozzilla renamed to Firebird

netscape firebird contraversy

Lisp Machines

What is Meet In The Middle Attack

IE6 faster than O7.10?

How to cope with missing values - NULLS?

How to cope with missing values - NULLS?

What is the best strongest encryption

Codd's death (x-post from a.f.c)

Rewrite TCP/IP

Rewrite TCP/IP

death of Edgar F. (Ted) Codd

Disk capacity and backup solutions

Lisp Machines

Lisp Machines

switching to KDE

vnet 1000th node anniversary 6/10

Mercury News 04-20-2003 Computer pioneer, dead at 79,

Lisp Machines

Rewrite TCP/IP

Advantages of multiple cores on single chip

OT What movies have taught us about Computers

OT What movies have taught us about Computers

40th Anniversary of IBM System/360

can't close tab after abort 1.3/1.4a

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

IBM zSeries in HPC

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

UT200 (CDC RJE) Software for TOPS-10?

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

software pricing

death of Edgar F. (Ted) Codd

IBM zSeries in HPC

rh9/evolution/filters

Simple resource protection with public keys

Alpha performance, why?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Alpha performance, why?
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 08 Apr 2003 20:01:21 GMT

Anne & Lynn Wheeler writes:

the clock that i did in the 60s .... and the stanford phd thesis on
clock (over ten years later) .... didn't tic a hardware clock. The

the big difference between the clock i did in the 60s as an
undergraduate (and the clock described in the stanford phd thesis over
ten years later) and the slight-of-hand i did circa '71 was that
traditional LRU replacement algorithms (including the various flavors
of clock) have a pathelogical degrade to FIFO ... where the
slight-of-hand trick i did ... degrade to random (and just like it was
possible to show that LRU was tradtionally better than FIFO .... it
was also possible to show ... in the region where LRU would degrade to
FIFO ... that random was better).
http://www.garlic.com/~lynn/subtopic.html#wsclock

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Share in DC: was somethin' else

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Share in DC: was somethin' else
Newsgroups: bit.listserv.ibm-main
Date: Wed, 09 Apr 2003 00:54:30 GMT

whp@MINDSPRING.COM (Bill Planer) writes:

More like 45 minutes in light traffic.  The Pentagon is in Arlington,
Va.  The WSC is in Gaithersburg, MD.

the 495/270 split can really back up ... and then there is still all
the construction going up the 270 side towards g'burg ... sometimes it
looks almost easier to take the democracy exit and head up rockville
pike.

WSC used to share the building with FSD ... i haven't been there since
FSD was sold off .... so don't how they manage it now; or where
federal marketing resides?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Share in DC: was somethin' else

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Share in DC: was somethin' else
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 09 Apr 2003 15:43:36 GMT

edgould@AMERITECH.NET (Edward Gould) writes:

It was early evening (6-7 PM) My friend had a corvette and I didn't
pay much attention. He picked me up in Crystal City (I was attending
an IBM 8100 class there)..

and that was? ... a question came up exactly when did 8100 get killed?
http://www.garlic.com/~lynn/2003e.html#65 801 (was Re: Reviving Multics
http://www.garlic.com/~lynn/2003f.html#22 Could somebody use SCSH, Sheme, or Lisp to create the "Lispm"

a couple times we had meetings in wsc ... we stayed in 'napolis; there
was a hilton(?) on the water ... which i believe is a marriott now
... something of commute.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Disk capacity and backup solutions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk capacity and backup solutions
Newsgroups: comp.arch,alt.folklore.computers
Date: Wed, 09 Apr 2003 16:05:04 GMT

Jouni Matti Juhani Osmala writes:

There are basicly TWO strategies in getting reasonable reliability.
A) get mainframe (high costs)
B) Redundant Array of Inexpensive Computers =RAIC

i think for something like 20 years it has been documented that the
major causes of failures has not been hardware, but software and
people mistakes.

one of the major costs associated with mainframes ... has been the
extensive software regression testing .... both from product
perspective ... but also local installation/datacenter change
control. the other is extensive automated processes eliminating human
involvement. RAIC potentially are prone to both human error and
software glitches.

misc. past refs to automated operator.
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/99.html#71 High Availabilty on S/390
http://www.garlic.com/~lynn/99.html#107 Computer History
http://www.garlic.com/~lynn/99.html#128 Examples of non-relational databases
http://www.garlic.com/~lynn/99.html#136a checks (was S/390 on PowerPC?)
http://www.garlic.com/~lynn/2000.html#22 Computer of the century
http://www.garlic.com/~lynn/2000f.html#12 Amdahl Exits Mainframe Market
http://www.garlic.com/~lynn/2001.html#43 Life as a programmer--1960, 1965?
http://www.garlic.com/~lynn/2001c.html#13 LINUS for S/390
http://www.garlic.com/~lynn/2001d.html#70 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001d.html#71 Pentium 4 Prefetch engine?
http://www.garlic.com/~lynn/2001e.html#44 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001e.html#47 Where are IBM z390 SPECint2000 results?
http://www.garlic.com/~lynn/2001h.html#8 VM: checking some myths.
http://www.garlic.com/~lynn/2001k.html#14 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001k.html#18 HP-UX will not be ported to Alpha (no surprise)exit
http://www.garlic.com/~lynn/2001l.html#47 five-nines
http://www.garlic.com/~lynn/2001n.html#47 Sysplex Info
http://www.garlic.com/~lynn/2001n.html#85 The demise of compaq
http://www.garlic.com/~lynn/2002.html#24 Buffer overflow
http://www.garlic.com/~lynn/2002e.html#68 Blade architectures
http://www.garlic.com/~lynn/2002h.html#73 Where did text file line ending characters begin?
http://www.garlic.com/~lynn/2002l.html#62 Itanium2 performance data from SGI
http://www.garlic.com/~lynn/2002n.html#27 why does wait state exist?
http://www.garlic.com/~lynn/2002o.html#14 Home mainframes
http://www.garlic.com/~lynn/2002p.html#54 Newbie: Two quesions about mainframes
http://www.garlic.com/~lynn/2003.html#37 Calculating expected reliability for designed system

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

saving country music

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: saving country music
Newsgroups: alt.folklore.computers
Date: Wed, 09 Apr 2003 17:15:35 GMT

well,
http://www.kfat.com/
http://www.kpig.com/kfat.htm

somewhere i use to have open-real, 3600', recorded mono (four tracks)
at the slowest speed on the recorder ... the last two weeks of kfat.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 10 Apr 2003 14:16:57 GMT

Mark Crispin writes:

I forget how the APL Life programs worked, since I never wrote any
of them.  At the time, I was still a baby programmer.  Later on, I
did write a basic wordprocessor in APL that I used to typeset a high
school term paper.

I think though that APL\360 itself was slow.  You didn't have all
that large a workspace -- I think 32K -- yet even memory primitives
took noticable time.

On the other hand, I don't know how fast a 360/67 was.  It was
supposed to have been one of the faster models of 360s (this was early
1970s) but I recall that a 360/30 was very slow.  The stupid prime
number calculation program (check all odd numbers from 3 to the square
root to see if any are a factor) was faster in interpreted FOCAL on a
PDP-8/e than in compiled Fortran on the 360/30.

if it was apl\360 on a '67 in the cambridge area in the early '70s, it
might have actually been apl\360 port to cms (cms\apl) done at
csc. workspace was opened up to be as large as the virtual memory
space given to cms ... which was typically at least as large as a
couple hundred k ... and might be a couple of meg. (although not
likely for student accounts). cms had hacked the apl garbage collector
so it wouldn't be so onerous in a virtual memory environment (with
16k-32k fixed workspace that was always swapped completely .... it
wasn't so noticeable that apl wanted to frequently touch every memory
byte it had available ... whether it needed it or not).

besides student accounts on csc machine ... there was at least the
cp/67 machine at mit urban planning (across the tech. sq court yard?).
http://www.multicians.org/thvv/360-67.html

in the above ref ... i had done the TTY support as an undergraduate,
and it was incorporated into the standard product. i had done some
trick with one-byte arithmatic (255) since tty would never come close
to exceedd that .... but later ascii devices did .. and when Tom
increased the max. size to larger than 255 ... the hack with one byte
arithmatic wasn't changed.

apl was interpreted ... and could easily be 10-50 times slower than
the same code compiled in fortran running on the same machine.

random apl (& hone) refs:
http://www.garlic.com/~lynn/subtopic.html#hone

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Oldest system to run a web browser?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Oldest system to run a web browser?
Newsgroups: alt.folklore.computers
Date: Thu, 10 Apr 2003 16:43:18 GMT

also 10 years ago ... a good percentage of the isp accounts were shell
... and/or uucp; with typically uucp being to periodically dial-up,
exchange email and then drop the line (aka uucp wasn't just used for
broadcasting usenet stuff).

also, one of the premier modems was telebit trailblazer (i still have
one in a box someplace) that had special optimization for uucp.

random past uucp &/or trailblazer postings:
http://www.garlic.com/~lynn/2000c.html#26 The first "internet" companies?
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2001b.html#57 I am fed up!
http://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
http://www.garlic.com/~lynn/2001e.html#62 Modem "mating calls"
http://www.garlic.com/~lynn/2001e.html#63 Modem "mating calls"
http://www.garlic.com/~lynn/2001h.html#65 UUCP email
http://www.garlic.com/~lynn/2001h.html#66 UUCP email
http://www.garlic.com/~lynn/2001j.html#20 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001j.html#45 OT - Internet Explorer V6.0
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001n.html#12 Author seeks help - net in 1981
http://www.garlic.com/~lynn/2001n.html#87 A new forum is up! Q: what means nntp
http://www.garlic.com/~lynn/2002b.html#53 Computer Naming Conventions
http://www.garlic.com/~lynn/2002e.html#6 LISTSERV(r) on mainframes
http://www.garlic.com/~lynn/2002f.html#13 Hardware glitches, designed in and otherwise
http://www.garlic.com/~lynn/2002i.html#44 Unisys A11 worth keeping?
http://www.garlic.com/~lynn/2002j.html#75 30th b'day
http://www.garlic.com/~lynn/2002k.html#21 Vnet : Unbelievable
http://www.garlic.com/~lynn/2002k.html#26 DEC eNet: was Vnet : Unbelievable
http://www.garlic.com/~lynn/2002m.html#48 History of The Well was AOL
http://www.garlic.com/~lynn/2002o.html#41 META: Newsgroup cliques?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Thu, 10 Apr 2003 18:43:02 GMT

jchausler writes:

The first light pen I saw in use was on an IBM 1130
in the late 60's.  I had already used a "Rand Tablet"
a few years before.  The light pen was a 50's
development which came out of the Project Whirlwind
for the AN-FSQ/7 development and SAGE.  I don't
know when the "Rand Tablet" was developed.  I
used it attached to a Philco graphics controller being
run by one of the Bendix G-20's at CMU in the 60's
(as kind of a background task, the G-20 was doing
other things as well).

light pen was on the 2250 ... there were several models of 2250s (any
which could have light pen, tablet, some number of other things);
... 2250m1, controller that was direct 360 channel attach. 2250m4 had
a 1130 as a controller.
random past

random past 1130/2250 refs:
http://www.garlic.com/~lynn/97.html#2 IBM 1130 (was Re: IBM 7090--used for business or science?)
http://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001f.html#13 5-player Spacewar?
http://www.garlic.com/~lynn/2001m.html#22 When did full-screen come to VM/370?
http://www.garlic.com/~lynn/2002i.html#20 6600 Console was Re: CDC6600 - just how powerful a machine was
http://www.garlic.com/~lynn/2002j.html#22 Computer Terminal Design Over the Years
http://www.garlic.com/~lynn/2002o.html#17 PLX
http://www.garlic.com/~lynn/2002p.html#29 Vector display systems
http://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003d.html#38 The PDP-1 - games machine?
http://www.garlic.com/~lynn/2003f.html#39 1130 Games WAS Re: Any DEC 340 Display System Doco ?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Redhat 9

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Redhat 9
Newsgroups: redhat.general
Date: Thu, 10 Apr 2003 18:54:38 GMT

Lars Dybdahl writes:

I would recommmend RH9 for RH7.3 users, but RH8 users should wait a
month or two.

i just upgraded from 7.3 to 9. most of it seem to have gone ok. the
apache 2.0 stuff seemed to be not quite right. running any of the
configurator stuff for http/apache on 9 ... doesn't actually do
anything for starting apache. /etc/init.d http file from 7.3 for
apache 1.3 is still left around and it looks like i have to manually
add the http startup to rc file.

also i can't find the pointer for the smp browser-based configuration
(which was used on 7.3)

also, i'm looking for a rh9 qmail.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Determining Key Exchange Frequency?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Determining Key Exchange Frequency?
Newsgroups: sci.crypt
Date: Thu, 10 Apr 2003 20:03:24 GMT

"Bret Schuhmacher" writes:

Can anyone direct me to texts/URLs covering the basics of
determining how often Symmetric (3DES) keys ought to be changed?
Can anyone give some guidelines for this decision?  The act of
actually exchanging keys is not that tough - I'm talking about how
often you should actually perform that action based on industry
standards and best practices.  I thought I read somewhere that
Visa/MC only do it once per quarter, but now I can't find that
resource anymore :-(.

note that x9 & financial infrastructre are now specifying derived
unique key per transaction (DUKPT) ...  a type of one-way function
that combines something like the account number, date/time and the
secret key. brute force attack on each transaction only recovers the
transaction specific derived key.

do search engine on dukpt, x9. etc; some quick examples:
http://www.trustedsecurity.com/POSsolutions.htm
http://www.futurex.com/products/excrypt/features.html
http://www.ccpcgroup.com/pinpad101.asp
http://www.advancedpayments.net/pinpad101.html
http://international.visa.com/fb/vendors/pin/faqs.jsp

you can also check my x9 glossary & taxonomy at:
http://www.garlic.com/~lynn/index.html#glossary

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Fri, 11 Apr 2003 03:04:31 GMT

johnl@iecc.com (John R. Levine) writes:

The /67 was a pretty fast machine for the mid 1960s with 32 bit
integer datapaths, 200ns cycle time, and a 60 bit adder for floating
point.  Register to register integer load or add was 650 ns,
memory-to-register load was 1.2us, add 1.4us.  Floating add from
memory 2.43us single, 2.45us double.  Floating multiply 4.4us short,
7.6us long.  Floating divide 7.3us short, 14.1us long.  Floating
compare 1.98us, conditional branch 800ns not taken, 1.1us taken.  The
dual processor machine was slightly slower, 690 ns load, to 14.33us
floating divide.

memory cycle was 750ns (the original models 360 60, 62, 70 were going
to have something like 1mic memory ... and the upgrade to 750ns
created 65, 67, & 75). the uniprocessor 67 was essentially nearly
identical to 65 with the addtion of associative array that could be
used when running in virtual memory mode.

running in virtual memory mode ... added 150ns to the memory cycle
time (for associative array aka TLB lookup) for 900ns.

i-fetch was double word ... so a 2byte register-to-register
instruction timing includes 1/4th of 750ns (900ns in virtual memory)
8-byte i-fetch. a 4byte rs/rx/ri instruction timing includes
1/2th of the 750/900 i-fetch.

so in virtual memory mode (900ns)

                       prorated i-fetch
2byte instruction           225ns          + execution
4byte instruction           450ns          + execution
6byte instruction           675ns          + execution

just about all 4byte instructions have a storage load/store of some
sort ... so a 4byte instruction would have 450ns+900ns or 1350ns
running virtual memory mode (prorated i-fetch plus one load/store)
base plus whatever instruction execution time.

what doesn't show in the manual is that the uniprocessor had single
ported memory ... heavy i/o could significantly degrade the actual
thruput because of contention for the memory bus.

The 67 dual processor was significantly different from the 65 dual
processor. The 65 dual processor was basically two uniprocessors
sharing the same, contiguous memory.

The 67 dual processor had tri-ported memory ... one port for each
processor and one port for i/o. Tri-ported memory slowed down base
memory cycle by about 150ns ... aka to around 900ns .... or 1050ns in
virtual memory mode (however, it avoided much of the memory bus
contention).

Note that a half-duplex 67 running in non-virtual memory mode with any
sort of reasonable I/O activity had measurably higher thruput than the
same workload on a simplex 67 or a 65 (aka while base memory bus time
on half-duplex 67 was slower than either uniprocessor 65 or 67, it's
tri-ported memory bus avoided much of the significant memory bus
contention from i/o activity).

cp/67 on half-duplex 67 (aka a single processor 67 with tri-ported
memory) outperformed same workload on simplex 67 (if there was any i/o
involved).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Speed of APL on 360s, was Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Speed of APL on 360s, was Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers,alt.sys.pdp10
Date: Fri, 11 Apr 2003 03:14:44 GMT

Anne & Lynn Wheeler writes:

Note that a half-duplex 67 running in non-virtual memory mode with any
sort of reasonable I/O activity had measurably higher thruput than the
same workload on a simplex 67 or a 65 (aka while base memory bus time
on half-duplex 67 was slower than either uniprocessor 65 or 67, it's
tri-ported memory bus avoided much of the significant memory bus
contention from i/o activity).

cp/67 on half-duplex 67 (aka a single processor 67 with tri-ported
memory) outperformed same workload on simplex 67 (if there was any i/o
involved).

.. and while apl\360 (under os/360 on 65 or 67 running in non-virtual
memory mode) programs might be primarily computationally intensive ...
there would typically be at least lots of i/o swapping workspaces in &
out.

HONE (possibly the largest time-sharing services in the world at the
time) ... was nearly all APL/CMS ... then vs/apl on cms, etc. The
whole interactive environment was large APL application controlling
the environment for the sales & field support people around the world.
However, there were some number of the configuration applications that
were so computationally intensive that it made it worth while to
rewrite them in fortran ... and have them execute outside the APL
environment (transparent to the end-user).

misc hone
http://www.garlic.com/~lynn/subtopic.html#hone

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Page Table - per OS/Process

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 05:03:42 GMT

Joshua Jones writes:

Page tables facilitate mapping virtual addresses to physical ones.
Each process has its own address space and therefore process A and
process B must have their own page tables.  Only having one page
table wouldn't make much sense, as it would provide no multiplexing
of memory (it would be simply an extra layer of indirection that
would slow things down).

the initial port of the various (real memory) 360 OS to 370 virtual
memory all did that. issue was the real storage sizes were typically
much smaller than the addressing size ... and multitasking had some
amount of contiguous memory per process. the larger virtual memory
size allowed larger number of concurrent processes ... w/o significant
rewritting of the base operating system. the increased flexibility of
scheduling additional processes tended to offset the virtual memory
overhead.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Page Table - per OS/Process

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 14:11:08 GMT

"Glen Herrmannsfeldt" writes:

I still remember lots of complaints about MVS when it came out, how
slow it was.  I don't know if that was really due to extra overhead
of separate page/segment tables or not.

It might be that the original 370's had to do PTLB on every change of
segment tables, and it would take some overhead to build the TLB back.

i don't think that the pathlength got any better ... the machines got
faster. in early '80s, mvs (and vm) got "big pages" which helped
any page I/O associated bottlenecks.

370/168 had 128 entry TLB ... but had a 7-entry STO-stack ... i.e. it
could keep track of seven different address spaces ... switching to a
new address space that wasn't in the STO-stack ... it would scavenge
one of the current (STO-stack) entries ... and (only) that address
space's TLB entries would be invalidated (aka a partial, implicit purge
lookaside ... PTLB).

original 370 architecture had PTLB, ISTO (invalidate address space),
ISTE (invalidate segment table entry), IPTE (invalidate page table
entry). Because of implementation problem/schedule with 370/165, all
but PTLB instruction were dropped in 370. The explicit instructions
were only used when software had to invalidatte tables. If there was
any page replaced and a virtual page table entry was invalidated, the
software/kernel had to do a PTLB. This originally wasn't considered a
problem by VS2 (original/official name) ... since they claimed
implementation would never do more than five page replacements a
second ... and that the implementation tended to do 5-10 replacement
selections in a batch (requiring a single PTLB).

3033 finally did implement IPTE (selective page table entry invalidate
... single virtual page).

the low-end 370s (which mvs didn't run on) tended to have a single STO
TLBS ... the TLBs typically only had 8 or so entries. While changing
an address space resulted in all TLB entries being purged ... it
wasn't as much of a problem. MVS didn't run on these machines ... so
it wasn't a problem for them .... and the operating systems (except
for VM/370) for the low-end machines ran with single address space.

some postings on 370 STO-stack:
http://www.garlic.com/~lynn/2000g.html#10 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001g.html#8 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2002c.html#40 using >=4GB of memory on a 32-bit processor
http://www.garlic.com/~lynn/2002l.html#60 Handling variable page sizes?
http://www.garlic.com/~lynn/2003e.html#0 Resolved: There Are No Programs With >32 Bits of Text

recent posting on mvs performance(?):
http://www.garlic.com/~lynn/2003f.html#51 inter-block gaps on DASD tracks

some recent discussion of big pages implementation:
http://www.garlic.com/~lynn/2003f.html#5 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#9 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#16 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#48 Alpha performance, why?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Page Table - per OS/Process

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Fri, 11 Apr 2003 23:43:23 GMT

"Glen Herrmannsfeldt" writes:

An STO stack sounds like a good idea.  So they implemented it even
though OS/VS2 wouldn't use it?  They were already planning for MVS?

initial OS/VS2 was called SVS .... single virtual storage ... already
getting ready for OS2/VS2 MVS ... multiple virtual storage. The issue
was that SVS was the minimum amount that needed to be done to MVT to
get it running in virtual memory environment.

Basically MVT was setup as if it had 16mbytes .... then hack ipl/boot
to PIN/FIX the contiguous kernel and setup the segment & page tables.
Start SVS (MVT-based) prototype (on 360/67) with the page fault
handler from CP/67 to handle page fault and be able to task
switch. Also hack CCWTRANS from CP/67 (function that copied CCWs aka
I/O commands, from virtual address space, translated virtual to real
addresses, fixed the associated pages in real memory for the duration
of the I/O, etc) into MVT-based prototype. misc. refs on this:
http://www.garlic.com/~lynn/2000c.html#34 What level of computer is needed for a computer to Love?
http://www.garlic.com/~lynn/2001b.html#18 Linux IA-64 interrupts [was Re: Itanium benchmarks ...]
http://www.garlic.com/~lynn/2001i.html#37 IBM OS Timeline?
http://www.garlic.com/~lynn/2001i.html#38 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#36 History
http://www.garlic.com/~lynn/2002l.html#65 The problem with installable operating systems
http://www.garlic.com/~lynn/2002l.html#67 The problem with installable operating systems
http://www.garlic.com/~lynn/2002p.html#49 Linux paging
http://www.garlic.com/~lynn/2002p.html#51 Linux paging

Similar process was done for DOS/VS and VS1.

Then they started on a whole number of things for MVS ... which
required a lot of restructuring. The base MVT design had the kernel as
part of the application address space. The initial MVS design had a
separate address space for each application with the same kernel
segments as part of each application address space (aka common/shared
segments, but since TLB was sto-associative ... there were lots of
duplicate TLB entries for kernel pages).

Theree were problems were semi-privilege subsystems like JES2
... which weren't part of the kernel but relied on the same
pointer-passing convention used thru-out the OS/360 genre operating
systems. With MVS, JES2 sitting in its own subsystem address space
would get a pointer to some data in an application (totally different)
address space. The solution was the COMMON area. The address space was
24-bit, 16mbytes, 16 1mbyte segments. The kernel had 8 1mbyte
segments, and the application area was nominally 8 1mbyte segments.
The COMMON area started out being a single 1mbyte segment taken out of
the application area. Data needed to be exchanged between address
spaces could be copied to/From the COMMON area, and the pointer
passing convention preserved. A problem was that the appetite for
space in the COMMON area grew quickly and it wasn't untypical for an
installation to have a 4mbyte COMMON area (also duplicate TLB entries)
So even tho there was now a 16mbyte address space for each
application, in fact 8mbytes of that was taken up by the shared/common
kernel and frequently 4mbytes taken up by shared/common COMMON
...leaving only 4mbytes for applications.

So come the 168 follow-on, the 3033; and there continued even more
pressure to increase the size of the 4mbyte COMMON area (aka each
subsystem running in the environment needed its own little dedicated
space of COMMON) ... potentially with nothing left for
applications. The solution was dual-address space support. When
semi-privilege subsystem was running, it could be run with two
different STOs (address space table pointer), its primary STO ... and
a different/secondary STO for application space it was doing work on
behalf of ... and it could use pointers passed from application
programs and reach directly into their address space.  This
significantly alleviated the pressure for constantly increasing the
size of the COMMON area. Dual-address space support did increase the
pressure on the 3033 TLB entries.

primary/secondary address space refs (from later machine)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.2.1.4?SHELF=&DT=19970613131822
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/3.2.1.5?SHELF=&DT=19970613131822

move to primary & secondary instruction (from later machine)
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.22?DT=19970613131822
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/10.21?DT=19970613131822

A common segment kludge was added to later machines for MVS to try and
cut down on all the duplicate/identical TLB entries ... w/o having to
make the change from STO-associative (aka address space) TLB to a
STE-associative (aka segment) TLB. basically if MVS was running on the
bare hardware ... and MVS flagged segment table entry as common
... then there need only be a single copy of associated page table
entries in the TLB.
http://www.garlic.com/~lynn/2002l.html#57 Handling variable page sizes?
http://www.garlic.com/~lynn/2002m.html#0 Handling variable page sizes?

basically, if a segment table entry was flagged as common ... then it
is almost as if it was a single/common address space hardware
implementation. On TLB lookup ... accept a TLB for this virtual
address ... if it is either 1) marked as a common entry or if it is 2)
marked for this address space. On TLB miss ... if the segment table
entry is marked as common ... load the new TLB entry as common
(otherwise mark it as address space specific). It is a multi-address
space environment with sort of kludge for a single system-wide shared
common space (implemented using a restricted use of shared segments
...  aka that all shared segment definitions have to be identical and
the same in all virtual address spaces).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Page Table - per OS/Process

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Page Table - per OS/Process
Newsgroups: comp.arch
Date: Sat, 12 Apr 2003 07:29:27 GMT

"Glen Herrmannsfeldt" writes:

I thought it wasn't called SVS until after MVS came out.  Though I
am not sure why they would keep calling it OS/VS2 after it was MVS.
I would have called it OS/VS3.

try this ...
http://os390-mvs.hypermart.net/mvshist2.htm

qHmm. Did the 360/67 have IDALs?  Otherwise it would have to keep
contiguous pages for I/O operations?

nope ... that was added with 370 ... cp/67 used data-chaining which
had some timing restrictions (that weren't encounted on the 360/67 but
would have been on some of the entry level 370). the initial prototype
for svs was mvt system running on 360/67 with the indicated hacks to
fake out most of mvt to think it was running in 16mbyte real machine,
kernel pinned, page fault handler, some stuff in task switch, and
cp/67's ccwtrans. the switch to idal support was already available.
However, the early testing on 360/67 was w/o the idal ... since the
360/67 didn't have idal support.

as related elsewhere ... there was joint project between cambridge and
endicott to build a cp/67 that ran on 370/145. A set of modifications
were done to a cp kernel that provided simulation for 370 instructions
and 370 virtual memory tables (and idals). Then a different set of
modifications were done to a cp kernel that used 370 instructions and
virtual memory tables.

Because of various security concerns (like lots of mit, bu, etc. students
using the cambridge machine), a version of the cp/67 kernel ran on
the bare hardware. In a virtual 360/67 virtual machine a modified
version of the cp/67 kernel was run that provided 370 virtual machines.
In a 370 virtual machine, a modified version of the cp/67 kernel that
ran on 370 real machines was run.

      360/67 real hardare  ran cp/67 providing virtual 360/67
         virtual 370/67 ran modified cp/67 providing virtual 370
            virtual 370 ran modified cp/67 providing virtual 360&360
              virtual 360/370 ran cms

This was all completed and was operational a year before the first
engineering model 370 hardware with virtual memory was available.
http://www.garlic.com/~lynn/2002h.html#50 crossreferenced program code listings
http://www.garlic.com/~lynn/2002j.html#0 HONE was .. Hercules and System/390 - do we need it?

note that when a 370/145 finally shipped to customers (see the mvs
history ref above), it did have the necessary hardware support for
virtual memory ... and only needed a microcode change to
enable. however, the early engineering models didn't initially have
virtual memory. the first software to be booted on the 370/145
engineering model with virtual memory was the modified cp/67 ... and
the "ipl button" was a knife switch.

The joint development project was also one of the first production
uses of vnet internal network for distributed development activity.
http://www.garlic.com/~lynn/internet.htm

topic drift with respect to the mvs history ref ... when i was hacking
around in the disk engineering lab ... trying to run MVS in the late
70s with engineering hardware under development ... had a MTBF of 15
minutes for MVS. As a result ... the standard operational mode was
dedicated machine time with simple "stand-alone monitor & test
programs". I documented the failures & necessary approach for fixing
them in a classified corporate document ... and put together a sytsem
that never failed from any of the hardware errors that the enginner
environment had (aka error activity in periods of minutes in the
enginner & product test labs would possibly not be seen in a normal
operation over a period spanning possibly years). There was some rumor
that the MVS RAS manager tried to cause lots of problems because of
the document (even tho is wasn't available to anybody outside of the
company). It sort of reminded me of when CERN did the MVS/TSO
comparison with CMS and published a report at SHARE in the early '70s.
The copy available within the corporation was given one of the highest
security classification and employees could only get copies if they
demonstrated strick need-to-know (or they got a copy from some
customer).
http://www.garlic.com/~lynn/subtopic.html#disk

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Disk capacity and backup solutions

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Disk capacity and backup solutions
Newsgroups: comp.arch,alt.folklore.computers
Date: Sat, 12 Apr 2003 14:55:30 GMT

jmfbahciv writes:

Right.  I also was sluing to another bandwagon of mine which
had to do with reproducibility of bit patterns.

besides doing cp/67, virtual memory stuff (besides cp/67 virtual
memory, things like vs/repack), the internal network,
http://www.garlic.com/~lynn/subtopic.html#bitnet
http://www.garlic.com/~lynn/internet.htm
gml (precursor to sgml, html, xml, etc), multiprocessing (including
the invention of the compare and swap instruction)
http://www.garlic.com/~lynn/subtopic.html#smp
etc .... there was lots of work at the science center on performance
monitor/instrumentation/tuning and the early stuff that became
capacity planning. there was a event simulator that could handle
instruction/page traces and compare different kinds of page
replacement algorithms in application that simulating cp/67.
http://www.garlic.com/~lynn/subtopic.html#545tech

with years of performance data ... not only from the cambridge
machine, but later from other cp/67 systems and then vm/370 systems
(some number of the thousands of internal corporate vm/370
installations) ... there was lots of early work done on workload
profiling.

once the apl/360 port to cms\apl at been done at the science center
... there was also a detailed analytical model of systems ... and
extensively calibrated from the years of recorded data. A version of
this (called the performance predictor) was made available fairly
early on the (field/sales support) HONE system ...
http://www.garlic.com/~lynn/subtopic.html#hone

salesman could take profiles on customer operations and then do
what-if regarding hardware changes (faster cpus, more memory, more
disk, different workload, etc).

A version of this was also done for preparing the resource manager for
customer distribution :
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

A configurable synthentic workload was created and a automated
benchmarking procedure was set-up. The nominal performance envelope
(storage, page i/os, file i/os, workingset, interactive, mixed mode,
batch, cpu, etc) was characterized from hundreds of internal
installations. This was used to somewhat specify an initial run of
several hundred benchmarks .... along the edge of the performance
envelope, at evenly distributed points within the performance envelope
... and some extremely (stressful) benchmarks well outside the nominal
performance envelope

one stressful benchmark had the avg. service time for a page fault of
1 second ... aka hardware running flat out at 300 page i/os per second
... the page request queue was so long it took an avg of full second
to service a page fault. Early on, the stressing might cause various
kinds system failures ... as part of the process all such failures
were identified and fixed. It was also a way of precipitating
hung-users/zombies (which a frequently some sort of timing stress)
.. which required a redesign and rewrite of the kernel serialization
process to eliminate all such instances (which then also became part
of the resource manager).

This was similar but different to the rewrite of the i/o system that I
worked on a couple years later to eliminate all instances of i/o activity
related kernel glitches/hangs (for the disk engineering lab):
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process
http://www.garlic.com/~lynn/subtopic.html#disk

So after several hundred benchmarks to characterize the performance
profile and the resource manager across wide range of factors ... the
apl analytical model was modified to take into considerations factors
from the previous benchmarks and then dynamically define the
characteristics of the next benchmark (system parameters, workload
profile, hardware resources, etc ... running as part of the automated
benchmarking process), attempting to find things like anomolous points
in the operational environment (basically trying to provide test
coverage). eventually 2000 benchmarks were run over a period of 3
months
http://www.garlic.com/~lynn/subtopic.html#bench

the idea of software test matrix we applied a couple generations later
when we were working on adding payment transaction processing for this
small client/server startup (eventually come to be called electronic
commerce):
http://www.garlic.com/~lynn/aadsm5.htm#asrn3
http://www.garlic.com/~lynn/aadsm5.htm#asrn4
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/2001f.html#75 Test and Set (TS) vs Compare and Swap (CS)
http://www.garlic.com/~lynn/2001n.html#91 Buffer overflow
http://www.garlic.com/~lynn/2001n.html#93 Buffer overflow
http://www.garlic.com/~lynn/2002n.html#11 Wanted: the SOUNDS of classic computing

of course, in-between the generations ... we did ha/cmp product:
http://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Can someone clarify, X509 spoofing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can someone clarify, X509 spoofing?
Newsgroups: sci.crypt,comp.security.misc
Date: Sun, 13 Apr 2003 01:25:29 GMT

Jem Berkes writes:

I wanted to make sure I had this point right about SSL and X.509
certificates. From what I understand, the X.509 certificate includes
just about all the data about an SSL host, including their public
key and signatures.

So if you connect to a host using SSL and record the hash of their
X.509 certificate, and store ONLY this hash... does this protect you
from spoofing on future connects? On each connect you can re-hash
the X.509 certificate returned to you and check it against the known
good hash.

i.e., can X.509 certs be spoofed so that their SHA-1 hashes meet a
known value? (I already know about the computationally infeasible
stuff.)

remember that the contents of the certificate have had SHA-1 which is
then "encrypted" with the private key of the certification authority's
private key to form the digital signature. This is assumed to be
unique and non-forgeable. What you then get as a certificate ... is the
content of the certificate with the certification authority's digital
signature.

Part of the process of validating a certificate .... is to recalculate
the SHA-1 of the contents of the certificate ... and then "decrypt"
the digital signature with the certificate authority's public key
(recoverying the original SHA-1) and compare the two values.

So the process on receiving a message from a SSL webserver .... is
that there sould be the contents of the message, the senders digital
signature of the message (i.e. SHA-1 of the message sent "encrypted"
with the sender's private key), with the certificate appended (which
in itself is a kind of message with the certification authority's
digital signature).

so you have the certification authority's public key stashed someplace
... and you get a message tuple (message, signature, certificate), you
validate the signature on the certificate ... calculating the SHA-1 of
the contents of the certificate against the "decrypted" signature,
using the certification authority's public key. If that works, you
take the sender's public key from the contents of the certificate, and
qcalculate the SHA-1 of the sender's message and compare it against
the "decrypted" SHA-1 (using the public key from the contents of the
certifcate).

loads of SHA-1s and loads of public keys ... w/o having to keep your
own SHA-1 ... just keep the public key of the certification authority.

Note to avoid "replay" attacks (imposter sending exact duplicate of
some previous message) ... you have to perform some amount of the
digital signature verfication.

If SHA-1 can be spoofed ... lots of other things fall apart ... long
before worrying your use of SHA-1.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Can someone clarify, X509 spoofing?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can someone clarify, X509 spoofing?
Newsgroups: sci.crypt,comp.security.misc
Date: Sun, 13 Apr 2003 19:05:19 GMT

"Ernst Lippe" <ernstl-at-planet-dot-nl@ignore.this> writes:

When the client certificate does not correspond with the
server private key, SSL will not be able to successfully
negotiate a correct session key.

At the moment I can't think of any serious attack that
would become possible if you happened to find two certificates
with the same hash. Under very specialized conditions
such attacks might exist, but until someone finds a
very good counter example, I don't see how this would
pose a threat against using certificates. After
all compromise of the private keys is a far more
realistic threat, and that doesn't appear to discourage
most users from using certificates.

if the reference is being able to modify the contents of a certificate
so that it matches any SHA of the original contents (whether it is a
saved copy or the certificates authority digital signature of the
contents) ... then one possibility is being able to alter the contents
such a different public key (matching some private in the attacker's
possession) is accepted. then the attacker could be accepted.

however, lots of discussions as to other points of attacks ... like
domain name take-over (that don't involve either direct attacks on
certificate contents or even direct attacks on private keys):
http://www.garlic.com/~lynn/subpubkey.html#sslcert

however, as mentioned in previous post ... if succesful attacks can be
mounted on SHA ... then the whole digital signature infrastructure is
at risk (not just somebody's private use of SHA).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Multiple layers of virtual address translation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple layers of virtual address translation
Newsgroups: comp.arch,alt.folklore.computers
Date: Mon, 14 Apr 2003 04:41:58 GMT

"Glen Herrmannsfeldt" writes:

Do you mean shadow page tables?  The guest OS (running in the
virtual machine) has its page tables, and VM has page tables mapping
guest real to host real.  Then VM generates shadow page tables that
go from guest virtual to host real and actually uses those.  Any
change to either of the others must be reflected in the shadow page
tables.  I believe it is PTLB that notifies VM of changes to page
tables, so it can update the shadow tables.

cp/67 & vm/370 were essentially the microcode of the virtual machine
and the "shadow tables" are effectively the equivalent of the TLB of
the virtual machine. CP/67 & VM/370 used similar rules for managing
"shadow tables" as real hardware used for managing TLB. Anything that
load entry into a TLB could also be used to load something into
"shadow tables" and rules for deleting TLB entries, the "shadow table"
maint used similar implementation (aka PTLB ... clear all entries, or
IPTE ... clear specific entry).

the virtual memory architecture was defined sufficiently so that it
could be arbritrary recursive ... the shadow table process could
cascade arbritrarily deep ... aka a kernel supporting a virtual
machine operation, couldn't differentiate between "standard" virtual
memory tables built in that virtual machine and what might be "shadow"
virtual memory tables. Maintenance of shadow table entries basically
followed hardware definition rules for maintaining TLB entries. There
were additional reasons why shadow table entries might get purged,
like kernel was removing one of the virtual machine's pages from
memory.

An early application was to implement a modified CP/67 that ran on a
370 architecture rather than a 360/67 architecture (for instance,
there were incompatible differences between 360/67 virtual memory
tables and 370 virtual memory tables). This was not only well before
370 virtual memory was announced and shipped to customers, but also
well before any engineering 370 processors supporting virtual memory
had even been built.

So a normal CP/67 ran on real CSC 360/67 (security issues because
there were MIT, BU students and other non-employees had access to the
CSC cp/67 service).  This "first level" CP/67 built 360/67 formated
virtual memory tables and emulated 2nd level 360/67 formated address
space tables using first level 360/67 formated shadow tables.

In a virtual 360/67 machine, a "2nd level" modified CP/67 ran which
provided virtual 370 machines. This modified cp/67 thot it was running
on real 360/67 and built 360/67 address space tables for the virtual
machines it provided. It emulated any 3rd level 370 formated address
space tables using 2nd level 360/67 formated shadow tables.

In a virtual 370 machine, a "3rd level" modified CP/67 ran which
provided virtual 370 machine (and believed it was running on real 370
machine). All its virtual memory tables (for the virtual machine
address space as well as emulating and tables might be built by the
"4th level" operation) were in 370 format.

recent related thread:
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process

all virtual memory tables built by the "3rd level" CP/67 cascaded into
"shadow tables" built by the "2nd level" CP/67. All virtual memory
tables built by the "2nd level" CP/67 cascaded into "shadow tables"
built by the "1st level" CP/67. The real hardware couldn't
differentiate between basic and shadow tables.

In any case, the "3rd level" Cp/67 (thinking it was running on real
370) was in regular operation a year before the first engineering 370
with virtual memory support was operational.

there is story that the ipl/boot button on the first engineering
machine was a knife switch, and ipl/boot of the modified cp/67 was
used to validate the hardware implementation. It turns out the initial
boot failed and the diagnosis was the hardware had incorrectly
implemented some facet of 370 (they had reversed the baker-two
opcodes for PTLB & RRB) ... the CP/67 kernel was quickly patched to
correspond to the incorrect hardware implementation (going thru and
swapping the B2 op-codes) ... and then (re)booted succesfully and ran.

the project was also an early example of distributed development
project between endicott and cambridge ... using the internal network
support.

little thread drift ...
last august was 30th anniversary of the VM/370 product announce at SHARE
1/1 was the 20th anniversary of the cut-over to internet protocol
march was the 35th anniversary of the CP/67 product announce at SHARE

coming up 6/10/2003 is the 20th anniversary of the 1000th node on the
internal network
http://www.garlic.com/~lynn/internet.htm#22

aka internet connectivity didn't really take off until after the
cut-over to internet protocol on 1/1/83 ... it wasn't until sometime
in 1985 that the number of nodes on the internet overtook the internal
network. In part, the internal network grew faster than arpanet
because it essentially had gateway function from the start ... while
arpanet was homogeneous network supported by IMPs and didn't get
heterogeneous and gateway functionality until cut-over to internet
protocol on 1/1/83.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Multiple layers of virtual address translation

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Multiple layers of virtual address translation
Newsgroups: comp.arch
Date: Mon, 14 Apr 2003 04:49:23 GMT

"Andy Glew" <andy-glew-public@sbcglobal.net> writes:

Pardon me. I should have asked exactly how the PTLB works.  I have a
habit of guessing, based on how I would implement something, but I
don't know what IBM actually did, and it may have done something
else.

...

PTLB ... purge look aside buffer

original 370 architecture had

PTLB ... purge look aside buffer
ISTO ... invalidate segment table origin (aka address apce)
ISTE ... invalidate segment table entry
IPTE ... invalidate page table entry
RRB  ... reset reference bit (little drift)

because of hardware implementation issues with 370/165 (that would
have delayed announcement and ship of 370 virtual memory product), the
selective invalidates; ISTO, ISTE, and IPTE were dropped from the
introduction of 370 virtual memory. IPTE did finally make appearance
with the 3033.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

price ov IBM virtual address box??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Mon, 14 Apr 2003 18:57:41 GMT

"Russ Holsclaw" writes:

The first large scale rollout of virtual address translation was
in the System/370's.  This line of computers was originally
announced and shipped (in 1970) with no mention of DAT (Dynamic
Address Translation) hardware, but the fact is that the hardware
was already there in almost all models (except the 195, IIRC).
When IBM finally announced the availability of VS system software
(sometime in '71 IIRC), IBM CE's were given instructions on how
to enable the DAT hardware already built into the 370's, so they
could use it.

155-II and 165-II were field hardware retrofit ... while 145, etc had
virtual memory hardware support with initial boxes shipped.

165-II was especially extensive and, in fact, some of the 370
architecture support for virtual memory was dropped ... because of
difficulty in 165-II implementation would have added six month delay
to general announcement (and customer ship) of virtual memory.

370/195 never did get virtual memory.

a specific reference ($200k for 155-II, and $400k for 165-II):
http://os390-mvs.hypermart.net/mvshist2.htm
http://os390-mvs.hypermart.net/mvshist.htm

recent mention of 165-II implementation issue:
http://www.garlic.com/~lynn/2003g.html#12 Page Table - per OS/Process
http://www.garlic.com/~lynn/2003g.html#19 Multiple layers of virtual address translation

folklore discussion of leakage of 370 virtual memory document before
product announce:
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000f.html#55 X86 ultimate CISC? No. (was: Re: "all-out" vs less aggressive designs)
http://www.garlic.com/~lynn/2002n.html#15 Tweaking old computers?

note many 360 and 370 machines had several rows of lights on the front
panel. there were "rollers" above above each light row which had
legends as to the meaning of the lights ... and rotating the roller,
switched the connections. On the 370/145 there was display of the PSW
and a light that had the label "DAT" (aka dynamic address
translation). This was on all 370/145 machines shipped to customers,
even before DAT (aka virtual memory) was announced.

other discussions:
http://www.garlic.com/~lynn/99.html#204 Core (word usage) was anti-equipment etc
http://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001.html#63 Are the L1 and L2 caches flushed on a page fault ?
http://www.garlic.com/~lynn/2001b.html#37 John Mashey's greatest hits
http://www.garlic.com/~lynn/2001c.html#7 LINUS for S/390
http://www.garlic.com/~lynn/2001k.html#8 Minimalist design (was Re: Parity - why even or odd)
http://www.garlic.com/~lynn/2002b.html#48 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002m.html#2 Handling variable page sizes?
http://www.garlic.com/~lynn/2002n.html#10 Coherent TLBs
http://www.garlic.com/~lynn/2003e.html#12 Resolved: There Are No Programs With >32 Bits of Text
http://www.garlic.com/~lynn/2003g.html#18 Multiple layers of virtual address translation

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

price ov IBM virtual address box??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Tue, 15 Apr 2003 04:03:58 GMT

shoppa@trailing-edge.com (Tim Shoppa) writes:

But as I understand it, this required different microcode.  Was there
any difference in speed for VM vs non-VM?  My experience is on PDP-11's,
and there if you ran without MMU you generally got a speed advantage
(varied depending on processor implementation).

discussion of 360/67 virtual memory hardware timing
http://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco ?

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

303x, idals, dat, disk head settle, and other rambling folklore

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: 303x, idals, dat, disk head settle, and other rambling folklore
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 15 Apr 2003 13:44:37 GMT

so i could remember the 67 timings for dat ... but not any of the 370
ones. i went looking on the ibm.com site for any old online functional
characteristic manuals (would give lots of the gory details of
instruction timings). i didn't find any, but stumbled across the 3033
references on the history pages ... aka
http://www-1.ibm.com/ibm/history/exhibits/3033/3033_room.html

so as per the 67 dat timings reference,
http://www.garlic.com/~lynn/2003g.html#21 price ov IBM virtual address box??
http://www.garlic.com/~lynn/2003g.html#10a Speed of APL on 360s, was Any DEC 340 Display System Doco

i also referenced that i/o contention for the memory bus had a lot of
impact on cpu instruction thruput. another issue was whether or not
there were integrated channels (i.e. the processor engine was
time-sliced between executing cpu instructions and executing i/o
instructions).

the 360/67 (and 65) had outboard, hardware channels. the 370/135,
370/145, 370,148, 4331, 4341, 370/155, 370/158 had integrated
channels, the 370/165, 370/168, and 303x processors had outboard
channels.

in the late '70s, i was doing this stuff for the fun of it supporting
the disk engineering and disk product test labs. one of the things was
timings having to do with disk head switch time on 3330 disk drives.
3330 had 19 tracks per cylinder (arm position) and a track had enuf
room for three 4k (page) records plus a little left over. the official
3330 specifications stated that if you wanted to read/write two
records on different tracks (requiring a head switch), the end of the
previous record read/wrote and the start of the next record read/wrote
had to be separated by at least a 110-byte intervening record. The
idea was to format every 3330 track with a three 4k records with
intervening "dummy/spacer/filler" records of 110 bytes. However, the
3330 track only had sufficient room for 101-byte filler records. past
discussion:
http://www.garlic.com/~lynn/2001b.html#69 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...

part of the issue was that i/o commands were executed by a sequence of
channel, control unit, and disk drive components, each having their
own latencies. Furthermore, i/o commands were stored in the processor
main memory and had to be executed stricly in-order with
no-prefetching (the archecture allowed that an i/o read from current
command could overlay/modify the next i/o command and/or the argument
of the next i/o command; so nothing could be fetched until the
termination of i/o transfer of the currently executing i/o
command). The impact was that command processing latencies were
strictly serialized and prefetching couldn't be used to compensate.

performing a head switch, not only requred the head settle time, but
also an additional i/o command in the process sequence (and the
associated serialized command processing latency). however, the 3330
110-byte "filler" specification was worst case scenario across a wide
range of processors and other hardware components;

processor model (145, 148, 4341, 158, 3033, etc)
channel implementation, integrated, or outboard
controller (3830, 3880, oem compatible)
drive (3330, from ibm or oem compatible)

so i wrote an application that would reformat a 3330 cylinder (19
tracks) with various dummy record sizes starting at 50-bytes and
increasing until it was no longer possible to fit three 4k records on
the track. it would run a series read/write i/o command sequences
testing to see if head switch was succesful using that dummy record
size. I then went to find a broad range of different configurations in
the san jose area to run it on. Also asked some customer shops to run
it also (bnr, cornell, etc).

data came back that there was some oem disk controllers that had
reduced command latency so that the succesful transfer of consecutive
records with head switch could occur with 50-byte spacer records,
regardless of the processor configuration.

The 148 and 4341 were succeful at 101-byte spacer records with
standard ibm controllers. The 158 failed, the 168 succeeded. In
addition, on all 303x processors failed, it failed. It turns out that
158 had integrated channels (the processor engine was time-sliced
between performing 370 instructions and i/o commands). For the 303x
series, they created something called a "channel director", an
outboard dedicated channel processor. A channel director was actually
the 158 processor engine w/o the 370 instruction processing
capability, purely dedicated to I/O function. However, it retained
most of the 158's integrated channel i/o command processing latency.

so in this other thread:
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process

the question about IDALs. CP/67 on 360/67 was able to simulate virtual
machine contiguous i/o transfers that crossed (non-contiguous) page
boundaries with the use of multiple data-chaining commands (separate
i/o commands that were separately fetched specifying different i/o
addresses). On various models of 370, morphing a single I/O command
into multiple data-chained commands, the processing latency would have
exceeded some timing constraints. Furthermore, not only was VM/370
going to be using this technique ... but all of the virtual operating
system would be translating contiguous transfer i/o that crossed paged
boundaries into non-contiguous transfers. The problem was addressed in
370 with the invention of IDALs ... instead of having the I/O command
directly specify the memory location of the transfer ... it could
point to "indirect address list", a series of address pointers.
Furthermore, sicne these weren't part of the original 360 i/o
architecture, they weren't subject to the constraint that they
couldn't be prefetched. A channel could prefetch as much of the IDAL
addresses as it needed in order to compensate for processing latency
(and overcome the serialized processing latency associated with the
data-chaining implementation).

now, the self-modifying i/o command stream was rarely used. NSC took
advantage of this in their remote device (A51x) adapter
implementation.  The A51x adapter simulated an ibm channel and could
be positioned at the end of a local HYPERchannel network or at a
remote HYPERChannel network connected by a telco link. Basically,
software in the processor would gather up all the I/O commands and
preload them into the memory of the A51x (effectively prefetching the
complete i/o sequence). This overcame any command processing latency
associated with transfer delays thru the HYPERChannel network. We used
this to relocate a couple hundred people of the IMS group out of the
STL lab to a remote location ten miles away (using T1 telco link) and
still provide them with "local" terminal support (see remote device
adapter refs below).

this initially didn't work with disk, because there were both timing
constraints associated with the actual I/O commands as well as
arguments of some specific commands. NSC came up with an enhanced
version of the A51x that supported preloading I/O commands as well
specialized disk i/o commands arguments. Besides allowing disks to be
placed at a remote distance, it also allowed implementation
(originally by NCAR) of one of the first SANs. An IBM processor
managed hiearchical storage of disk and tape for some number of other
processors like Crays. The processors and disk drives were all
interconnected by a common HYPERChannel network. Cray could request
access to data from the IBM processor, the ibm processor would locate
it on disk (transferring tape to disk if necessary) and return to the
cray an argument enabling the cray to directly request the data from
disk. This later showed up as requirement in IEES standard for HiPPI &
IPI disks for 3rd party transfer support.

partway back to 3033 refs on the ibm historical site. cp/67 and then
vm/370 was this non-standard product done initially by a couple people
located on the mit campus. it was not the flagship product, however
customers kept demanding it, despite the best efforts of the
corporation to stamp it out. people working on the project were
continuly told that the next release was the last and promotions and
raises were only possible if you transferred to work on the flagship
product. Despite the corporations best efforts, (cp/67 & then) vm/370
kept growing (both customers and the number of developers). Eventually
the vm/370 group overflowed the space available in 545 tech. sq and
they moved out to the old SBC building in burlington mall. During this
period, CERN presented the tso/cms comparison at SHARE ... and copies
of the document inside the corporation were promptly given one of the
highest security classification and were only available on strictly
need-to-know basis (unless you could get it directly from a customer).

In '76, the corporation told the vm/370 group that burlington was
being shutdown, the last VM/370 release had been shipped and everybody
had to move to POK to work on the VMTOOL (a virtual machine
implementation that would never be shipped to customers, dedicated to
supporting MVS/XA development). At this time, some number of people
didn't transfer to POK but wandered off to DEC and worked on VAX/VMS
(note customers did continue to get additional vm/370 releases and
VMTOOL was eventually made available to customers as VM/XA).

and finally back to the 3033 historical site
http://www-1.ibm.com/ibm/history/exhibits/3033/3033_intro.html

it turned out that somebody realized that the first 3033 install was
going to be some customer out west for vm/370. this was going to be
horrible loss of face for the flagship operating system. with some
quick last minute fiddling, truck routings and people scheduling ...
a truck from POK to New Jersey managed to arrive first (there were
some gov. constraints effectively about products having to be shipped
out of the manufacturing loading dock in the sequence that the orders
were placed, so there wasn't a lot of latitude available to the people
trying to save face).

misc idal refs:
http://www.garlic.com/~lynn/2002d.html#51 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002d.html#52 Hardest Mistake in Comp Arch to Fix
http://www.garlic.com/~lynn/2002e.html#21 Crazy idea: has it been done?
http://www.garlic.com/~lynn/2003d.html#26 Antiquity of Byte-Word addressing?

misc. cern tso/cms
http://www.garlic.com/~lynn/98.html#28 Drive letters
http://www.garlic.com/~lynn/2000e.html#23 Is Tim Berners-Lee the inventor of the web?
http://www.garlic.com/~lynn/2000f.html#61 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)
http://www.garlic.com/~lynn/2001f.html#49 any 70's era supercomputers that ran as slow as today's supercompu
http://www.garlic.com/~lynn/2001h.html#11 checking some myths.
http://www.garlic.com/~lynn/2001i.html#30 IBM OS Timeline?
http://www.garlic.com/~lynn/2001l.html#20 mainframe question
http://www.garlic.com/~lynn/2001m.html#19 3270 protocol
http://www.garlic.com/~lynn/2001m.html#43 FA: Early IBM Software and Reference Manuals
http://www.garlic.com/~lynn/2001n.html#37 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002b.html#46 ... the need for a Museum of Computer Software
http://www.garlic.com/~lynn/2002g.html#67 Coulda, Woulda, Shoudda moments?
http://www.garlic.com/~lynn/2002i.html#37 IBM was: CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#37 VR vs. Portable Computing
http://www.garlic.com/~lynn/2002n.html#73 Home mainframes
http://www.garlic.com/~lynn/2003g.html#14 Page Table - per OS/Process

NCAR/SAN refs:
http://www.garlic.com/~lynn/2001.html#21 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2001.html#22 Disk caching and file systems.  Disk history...people forget
http://www.garlic.com/~lynn/2002.html#10 index searching
http://www.garlic.com/~lynn/2002e.html#46 What goes into a 3090?
http://www.garlic.com/~lynn/2002g.html#61 GE 625/635 Reference + Smart Hardware
http://www.garlic.com/~lynn/2003b.html#29 360/370 disk drives

other hyperchannel remote device adatper refs:
http://www.garlic.com/~lynn/93.html#2 360/67, was Re: IBM's Project F/S ?
http://www.garlic.com/~lynn/94.html#23 CP spooling & programming technology
http://www.garlic.com/~lynn/94.html#24 CP spooling & programming technology
http://www.garlic.com/~lynn/96.html#27 Mainframes & Unix
http://www.garlic.com/~lynn/2000c.html#65 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000c.html#68 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2002f.html#60 Mainframes and "mini-computers"
http://www.garlic.com/~lynn/2002i.html#43 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2003c.html#64 Surprising discovery
http://www.garlic.com/~lynn/2003c.html#66 FBA suggestion was Re: "average" DASD Blocksize

misc burlington mall, vmtool, etc
http://www.garlic.com/~lynn/94.html#2 Schedulers
http://www.garlic.com/~lynn/98.html#7 DOS is Stolen!
http://www.garlic.com/~lynn/99.html#179 S/360 history
http://www.garlic.com/~lynn/2000b.html#54 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2000b.html#55 Multics dual-page-size scheme
http://www.garlic.com/~lynn/2001m.html#38 CMS under MVS
http://www.garlic.com/~lynn/2001m.html#47 TSS/360
http://www.garlic.com/~lynn/2001m.html#49 TSS/360
http://www.garlic.com/~lynn/2001n.html#67 Hercules etc. IBM not just missing a great opportunity...
http://www.garlic.com/~lynn/2002e.html#27 moving on
http://www.garlic.com/~lynn/2002h.html#34 Computers in Science Fiction
http://www.garlic.com/~lynn/2002h.html#59 history of CMS
http://www.garlic.com/~lynn/2002j.html#17 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002m.html#9 DOS history question
http://www.garlic.com/~lynn/2002o.html#78 Newsgroup cliques?
http://www.garlic.com/~lynn/2002p.html#14 Multics on emulated systems?
http://www.garlic.com/~lynn/2003c.html#0 Wanted: Weird Programming Language
http://www.garlic.com/~lynn/2003d.html#8 IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
http://www.garlic.com/~lynn/2003f.html#53 Alpha performance, why?

303x channel director refs:
http://www.garlic.com/~lynn/97.html#20 Why Mainframes?
http://www.garlic.com/~lynn/98.html#23 Fear of Multiprocessing?
http://www.garlic.com/~lynn/99.html#7 IBM S/360
http://www.garlic.com/~lynn/99.html#176 S/360 history
http://www.garlic.com/~lynn/99.html#187 Merced Processor Support at it again
http://www.garlic.com/~lynn/2000.html#78 Mainframe operating systems
http://www.garlic.com/~lynn/2000c.html#69 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#11 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#12 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#21 S/360 development burnout?
http://www.garlic.com/~lynn/2000g.html#11 360/370 instruction cycle time
http://www.garlic.com/~lynn/2001b.html#83 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#3 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001c.html#6 OS/360 (was LINUS for S/390)
http://www.garlic.com/~lynn/2001i.html#34 IBM OS Timeline?
http://www.garlic.com/~lynn/2001j.html#3 YKYGOW...
http://www.garlic.com/~lynn/2001j.html#14 Parity - why even or odd (was Re: Load Locked (was: IA64 running out of steam))
http://www.garlic.com/~lynn/2001l.html#24 mainframe question
http://www.garlic.com/~lynn/2001l.html#32 mainframe question
http://www.garlic.com/~lynn/2002.html#36 a.f.c history checkup... (was What specifications will the standard year 2001 PC have?)
http://www.garlic.com/~lynn/2002.html#48 Microcode?
http://www.garlic.com/~lynn/2002d.html#7 IBM Mainframe at home
http://www.garlic.com/~lynn/2002f.html#8 Is AMD doing an Intel?
http://www.garlic.com/~lynn/2002i.html#19 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#21 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002i.html#23 CDC6600 - just how powerful a machine was it?
http://www.garlic.com/~lynn/2002n.html#58 IBM S/370-168, 195, and 3033
http://www.garlic.com/~lynn/2002p.html#59 AMP  vs  SMP
http://www.garlic.com/~lynn/2003.html#39 Flex Question

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

price ov IBM virtual address box??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Tue, 15 Apr 2003 18:03:45 GMT

"Russ Holsclaw" writes:

I stand corrected. Interesting that folks with a lowly 145 got
DAT for free, but the high-end customers had to pay big bux. Of
course, I'm sure the performance was in a different league.

360/67 dat was fully associative eight entry array. however all
entries flushed every time CR0 was reloaded (segment table/address
space pointer). dat/tlb was/is hardware cached (page table) entries
for virtual->real address mapping ... the DAT lookup added 150ns to
every memory access (translating virtual->real address) ... if there
was a dat entry ... otherwise a dat-miss had to reference the real
segment/pagetables which were a couple full storage access).

370s were TLB ... table lookaside buffer ... and entries tended to be
indexed, possibly 2-way or 4-way associative.  CR0 became a series of
flag/option bits, and the segment table/address space pointer was
moved to CR1. 145 was 8(?) entry TLB and only handled a single address
space (flushing all entries every time cr1 was reloaded). 165/168 tlb
with 128 entries and 7-entry sto-stack discussed in refs indicated in
previous posting.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

UltraSPARC-IIIi

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: UltraSPARC-IIIi
Newsgroups: comp.arch
Date: Tue, 15 Apr 2003 18:59:09 GMT

hack@watson.ibm.com (hack) writes:

P.S.  PAE looks stupid only when 64-bit registers are available for
addressing.  In a 32-bit system it wasn't stupid at all.  IBM
did its own 26-bit PAE to escape from 24-bit constraints over
20 years ago, before 31-bit XA was introduced.  Why 24-bit
addressing lasted so long (given that 32-bit registers were
available -- and, in fact, 360/67 did support 32-bit virtual
addrs) is a different (and sad) story... mostly software.

cp/67 didn't use 32bit ... in part because it's interactive monitor
(cms) cribbed a lot of straight 24-bit stuff from os/360.

the official operating system for 360/67 was tss/360, which included
support for both 24-bit and 32-bit modes. during the 1967 period,
there was possibly at most 10 people in cambridge working on cp/67 and
cms ... while the tss/360 group had something like 1000-1200 people.

it is possible that having two orders of manitude fewer people made it
difficult to have a great deal of bloat with either software and/or
pathlength (in cp/67).

in the first half of '68 (before I had done much of my performance
optimization on cp/67), 30 users doing typical fortran development,
edit, compile & test with cms ... had better thruput and response than
four user doing same exact work under tss/360 on the same exact
hardware.

another big distinction was that cp/67 deliverables included full
source (where tss/360 provided some approximate microfiche).

I remember that the IBM SE (on the univerisity account) dedicated to
TSS/360 had some offshift and weekend time for testing. This
particular incident was at about tss/360 prerelease 0.69. Over a
period of several weeks, he had found and fixed (via binary patches)
something like six dozen bugs; documented everything and set it off to
the tss/360 development group in mohansic. he got back a message
saying that they couldn't use any of his work because they were in the
process of shipping pre-release 0.70 ... but they would be happy to
accept his work if repeated against the brand new 0.70 release (and he
got it to them before the 0.71 release).

tss found renewed life as tss/370 in custom circumstances. One saw
fairly wide use in AT&T with a port of Unix on top the "SSP" layer
built from tss/370. minor unix/tss ref:
http://www.garlic.com/~lynn/96.html#4a

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

303x, idals, dat, disk head settle, and other rambling folklore

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: 303x, idals, dat, disk head settle, and other rambling folklore
Newsgroups: comp.arch,alt.folklore.computers
Date: Tue, 15 Apr 2003 23:20:33 GMT

"Glen Herrmannsfeldt" writes:

I wonder about data chaining.  There was a story about someone
writing a whole tape reel with one record using data chaining, as
the maximum for one CCW was 64K-1.  (I believe it is -1, unlike
MVC).  It wouldn't seem to have much time to fetch the next CCW,
though.

MVC & other SS length instructions counted from zero ... i.e. to move
one byte, specify zero, to move 256 bytes, specify 255 (note that
assembler handled the conversion from assembler origin 1 specification
to machine instruction origin 0 specification) ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/A.2.2?SHELF=&DT=19970613131822

extract from above:

When SS-format instructions are written in the assembler language,
lengths are given as the total number of bytes in the field. This
differs from the machine definition, in which the length field
specifies the number of bytes to be added to the field address to
obtain the address of the last byte of the field. Thus, the machine
length is one less than the assembler-language length. The assembler
program automatically subtracts one from the length specified when the
instruction is assembled.

.....

CCW length counted from 1 ... to move one byte, specify one. CCW count
field is 2bytes ... so x'FFFF' is 64k-1.

there are now two different CCW formats; format 0 and format 1
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.3?DT=19970613131822

extract from above:

Count: Bits 48-63 (format 0) or bits 16-31 (format 1) specify the
number of bytes in the storage area designated by the CCW.

....

description CCW chaining ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6?DT=19970613131822
data chaining
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6.1?SHELF=&DT=19970613131822
command chaining ...
http://publibz.boulder.ibm.com/cgi-bin/bookmgr_OS390/BOOKS/DZ9AR004/15.6.6.2?SHELF=&DT=19970613131822

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM says AMD dead in 5yrs ... -- Microsoft Monopoly vs. IBM
 monopoly
Newsgroups: alt.folklore.computers
Date: Wed, 16 Apr 2003 00:34:18 GMT

Charles Shannon Hendrix writes:

White collar has always been the best way to steal, especially from a
government office... :)

while not strictly equivalent to white collar ... insider fraud has
frequently represented 90 percent of total fraud (aka white collar
isn't strictly insider and insider isn't strictly white collar).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

SYSPROF and the 190 disk

From: Anne & Lynn Wheeler <lynn@garlic.com>
Date: Wed, 16 Apr 2003 00:12:37 -0600
Newsgroups: bit.listserv.vmesa-l
Subject: re: SYSPROF and the 190 disk

At 12:01 AM 4/16/2003 -0500, wrote:

I'm fairly certain that INSTSEG did not come about until the days of
VM/XA.  I can't speak to HPO, as we never ran it.  However, my
understanding is that HPO simply contained performance enhancements on
a VM/SP base.  My recollection is that you couldn't load EXEC's into
a DCSS until VM/XA.  Perhaps the line was really in VM/SP 6.  I don't
suppose it really matters at this point.  Prior to VM/XA, however, you
had to code DMKSNT in order to do save segments.  Remember those bad
old days???!!!  Its my recollection that INSTSEG came about after
DCSS' became more dynamic and we waved good riddence to DMKSNT.

basically DMKSNT was left over from CP/67 .... and could only be
accessed by IPL command.

tail end of cp/67 days ... i had done a page mapped file system for
CMS on cp/67 with some enhanced capability for also specifying shared
objects from the mmap'ed API. I ported this to an early release 2
version of VM/370 and put it up on some number of internal operations.

Possibly on of the largest online time-sharing system (anywhere) at
the time was HONE which was vm/cms system supporting majority of the
field and sales people around the world. It was primarily written in
APL. Majority of accounts had login to automatically ipl "APLCMS"
DMKSNT entry ... this was a CMS system that had been saved after APL
had been loaded (and included both the CMS segment 1 and the segments
in the user area occupied by APL.

The problem they HONE was facing was that some of the applications,
possibly configurators (allowed salesman to actually fill-out
processors orders) were getting quite computationally intensive. Some
of these were recoded in Fortran getting a significant performance
improvement. However, it was quite a problem to have a salesman who
possibly never heard of CMS, APL, IPL commands, etc .... to get them
to drop out of APL, re-ipl a standard CMS, run the fortran program,
and then re-ipl APLCMS. So for their Relase 2 PLC system ... i
installed the support for the CMS page mapped filesystem .... it would
automatically recognize whether a minidisk was in page mapped format
or normal format ... and do the correct thing.

This new function supported doing the standard CMS IPL thing .... with
an additional shared segment that had a bunch of more stuff in
it. There was also some slight of hand that I had done that supported
floating shared segments .... so that the additional CMS "kernel"
shared segment was positioned at the end of the virtual address space
for each virtual machine. This met that the same exact shared segment
could appear at different virtual address in different virtual
machines/address spaces. I had done a quick and dirty hack for SVC 202
adcon ... by allocating an SVC202 and DC/AL4 return address in NUCON
.... since it wasn't possible to use a DC AL4 following an SVC 202
...... if the same R/O code might appear simultaneously at different
virtual addresses.

It was also possible to load an APL module after IPL ... with all the
appropriate segments initialized as R/O. It was now possible to have
virtual machines setup to automatically IPL CMS (the same version, for
all users, regardless of virtual machine size) and then automatically
invoke APL (and get all the appropriate shared segments). It was then
possible to write applications that dropped out of APL
... automatically invoke fortran programs and then re-enter APL
.... and it all worked the same whether they were running a shared
segment version of APL ... or a non-shared segment (normal CMS module)
version of APL.

Come up to items for release 3, the CMS group wanted the additional
shared segment definition for the kernel and the ability to invoke
shared segments with something other than the IPL command. However,
the CP group didn't want to pick up all of the function. So the CP
group picked up some of the underlying infrastructure "as-is" (likes
hits to routine responsible for creating/destroying segments
... shared or not shared) ... but they didn't pick up the rest of the
code .... just defined a restricted subset API that became referred to
as DCSS (discontiguous shared segments). The CP support to have the
same shared segment appear at different virtual address in different
address spaces also wasn't preserved.  However, the CMS group picked
up much of the code "as-is". I had gone thru some amount of code that
previously had been in shared segments .... and made it operational in
a R/O shared segment environment ... and at the same time "sanitized"
it to remove address location dependency (aka instead of inline SVC202
& inline DC AL4 adcons .... it used the SVC202 & AL4 in NUCON .... and
dynamically filled in the AL4 as part of the BAL to the SVC$202 in
NUCON). So while the CP group drop pieces of the support in preparing
it for release (like the support for "floating" shared segments)
... the CMS group picked up and distributed the code pretty much as
is.

Now since the additional CMS nucleus shared segment couldn't float to
the end of each virtual machine's address space ... the typical
process was that two or three different copies of the same exact code
were saved as different DCSS at different fixed virtual address. Then
there was some installation stuff about which DCSS copy that different
CMS configurations might load.

And of course ... then with DCSS, there was DMKSNT entries that could
be defined for other things like APL, SCRIPT, EDIT, etc. This had to
be generated and then savesys done with the respective DMKSNT entry.

In the page mapped file version (the other stuff not picked up as part
of the extended virtual memory management features as part of the
vm/370 release 3)... all of that had gone away. CMS just saved the
module to a page mapped minidisk with optional additional segment
specifications for the genmod command. The CMS loadmod command then
looked for the additional information and passed it when invoking the
CP page map API. Rather than needing DMKSNT entries for obtaining a
page mapped image (or later VM/XA doing it in the spool file system)
... the page map format and API .... had everything on CMS minidisks
already in page mapped format.

I had done some other things as part of the page mapped filesystem
changes .... including interface for doing contiguous record
allocation if the space was available. Before that, CMS would pretty
much do scatter allocate on a record by record basis. You could
sort-of get a kind of contiguous allocation by backing everything to
something like tape, doing an access/erase, and then reloading all the
files. However, you could still get some funny allocation with things
like hyperbloks intermixed with datablocks.

Yorktown then did a number of things in the release 5/6 time-frame
... the work on being able to copy S/Y/etc minidisk file directory
image into a DMKSNT saved segment and have it load when CMS ipl'ed.
In that time-frame, they had also done the (non-shared) nucleus
extension command ... being able to load a "module" at an arbitrary
address. This had some of the same issues as relocating shared
segments .... however it wasn't that they had r/o code, they had
private memory which could support adcons pointing to correct location
... their problems was that the GENMOD module-image already had all
its addresses fixed up. the nucleus extension loading a module at an
arbitrary address didn't have any information that enabled it to go
thru and fixup any adcons. At this time, the hack I had done for
SVC$202 in low-core was replaced with the AL4(1) convention.

In any case, the full package that the DCSS stuff for VM/370 release 3
was extracted from, had already eliminated DMKSNT as well as
eliminating any CP sensitivity for saving/loading shared stuff. The
DCSS subset was what had re-introduced DMKSNT when it was incorporated
for product release. The full implementation allowed quite a bit of
flexibility for mapping data on page-mapped minidisks into the virtual
address space (including shared segment specification options). It
then became purely a CMS operational and administrative issue with no
involvement of CP. It was only shipping a very restricted subset of
the full package that required reverting to DMKSNT.

recent postings on relocatable/floating code:
http://www.garlic.com/~lynn/2003f.html#20 Alpha performance, why?
http://www.garlic.com/~lynn/2003f.html#32 Alpha performance, why?

generail postings on mmap support:
http://www.garlic.com/~lynn/subtopic.html#mmap

Any DEC 340 Display System Doco ?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Any DEC 340 Display System Doco ?
Newsgroups: alt.folklore.computers
Date: Wed, 16 Apr 2003 19:46:53 GMT

"Charlie Gibbs" writes:

Yup, it's a crap shoot.  At a PPOE we ran 38400 bps over a twisted pair
to an X terminal at the other end of the building (100 feet?) and never
had any problems.  You pays your money and you takes your chances.

in the mid-80s, the brand new research bldg that had been wired for
CAT5  went almost totally to enet shielded twisted pair over cat5
(using synoptic hubs).

in the same area, there was a large, older research facility built in
the '60s that had a large excess of standard telco (unshielded)
twisted pair thru-out the bldg. it took a little more work to get enet
unshielded twisted pair working in all rooms and offices thru-out the
facility (again using synoptic hubs). in cases, some twisted pairs
were just dead ... guesses that various remodeling activities over the
years had cut/broken wires.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Wed, 16 Apr 2003 20:06:44 GMT

Toon Moene writes:

>There appears to be a common misconception in this thread that at the
>time Unix was created it was the only `real' operating system in the
>sense that it provided a protected kernel.

Ye Gods !  Are there people out there who actually believe that ?!?!?

Read Fred Brooks's "Mythical Man Month", some history stuff about
Multics and the conclusion is inevitable: Unix is Multics' second
system effect.

cp/67 had a protected micro-kernel ... in the same time-frame as
multics and had significantly wider deployment (some number of people
that had worked on ctss went to 4th floor, 545 tech sq and worked on
cp/67, others went to 5th floor, 545 tech sq and worked on multics).

cp/67 also had early deployment in some number of time-sharing service
bureau operations ... where the rule-of-thumb would have been a large
collection of essentially authorized and unauthorized users from all
over the world, sharing the same system(s) ... and all requiring
protection from each other.

the 545 tech sq cp/67 system was also used by corporate hdqtrs people
for analyzing the absolutely most/highest senstive corporate data,
while there was also concurrent availability to non-employees, like BU
and MIT students (some with the apparent intent of cracking the system
based on various indications).

there is some indication that cp/67 saw possibly wide-spread
deployment in sensitive, secure operations ... based on some active
participants at SHARE (customer organization).

the follow-on to cp/67 was vm/370 ... not exactly a 2nd system effect,
just a port from 360/67 architecture to 370 architcture.

misc. 545 tech. sq
http://www.garlic.com/~lynn/subtopic.html#545tech

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

One Processor is bad?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One Processor is bad?
Newsgroups: bit.listserv.ibm-main,alt.folklore.computers
Date: Wed, 16 Apr 2003 21:11:49 GMT

dba@DUDA.COM (David Andrews) writes:

IBM used to tell you that a dual-processor system would yield a
170-180percent increase in apparent capacity.  I know things have
improved since sysplex but probably not as much as you seem to
think.

(I've always been a fan of large unis, BTW.  When you're lightly
loaded, those jobs run at the speed of the complex and not at the
speed of a single processor.)

370 158/168 dual processor had a 10percent cycle slow down to allow
for handling cross-cache invalidates ... aka base instructions timings
were .9 of a uniprocessor. two processors running at .9 were 1.8.
This was only for the slowdown that allowed for handling cross-cache
invalidates, there was additional overhead for the actual handling of
cross-cache invalidates (as opposed the slowdown to provide for
handling them).

actual running dual processors at 1.8 could have handling of
cross-cache invalidates that slowed the machine down further ...
another 5-10 percent ... and the operating system overhead for running
in multiprocessing environment could be as much as 20-30 percent.
realistic thruput could easily be only 1.5 times.

the original VM/370 support for two processors came very close to
achieving the 1.8 times (magic slight of hand for coordinating two
processors with little or no measurable overhead). There were some
later changes to make the vm/370 two processor support more analogous
to mvs ... which introduced new measurable kernel activity directly
attributable to multiprocessor specific handling pathlength of approx.
ten percent of elapsed time.
http://www.garlic.com/~lynn/subtopic.html#smp

i first handled high priority compute bound jobs running away with
(any) processor with the early cp/67 implementation of the dynamic
adaptive resource manager (when i was an undergraduate). This was
dropped in the initial port from cp/67 to vm/370 ... but was later
re-introduced by the resource manager product:
http://www.garlic.com/~lynn/2001e.html#45 VM/370 Resource Manager
http://www.garlic.com/~lynn/subtopic.html#fairshare

they played a trick on me, saying that i got to be the guinea pig for
the first priced SCP software ... and I needed to spend a lot of time
with the business people figuring out the rules for SCP software
pricing.

part of the expertise was that a large amount of early 360
multiprocessor investigation was done at csc (cp/67, vm/370, 545
tech. sq) which also resulted in the Compare And Swap instructions for
the 370 (CAS is the person's initials at csc responsible for a lot of
pioneering MP work ... the challenge was to invent a mnemonic for his
initials).

3081 initially came out with only multiprocessor configuration (and
there was no mention of the multiprocessor "slow-down" since there was
never going to be a non-multiprocessor). The 4-way 3084 had a really
difficult time since the number of cache invalidate signals tripled;
aka in a 2-way, a cache would see cache invalidates from one other
processor; in a 4-way, a cache would see cache invalidates from three
other processors).

However, TPF (ACP, whatever) didn't have multiprocessing support
(although there were some number of standard 3081 configurations where
there was two copies of TPF running under vm/370). The 3083 single
processor was later addition ... and probably motivated by the lack of
TPF multiprocessor support. In 370, the standard was a uniprocessor
and reference to dual-processor was always with respect to
"slow-down".  The 3081 wasn't suppose to have a uni-processor ... and
when the 3083 did appear, the reference was to how much faster it ran
(i.e. the 10percent cache slow-down for catching cross-cache
invalidates was turned off).

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Wed, 16 Apr 2003 22:16:06 GMT

aek@spies.com (Al Kossow) writes:

"Plan to throw the first one away"

Unfortunately, what happens is you make compromises to SHIP the first
product, then the second product is the one with everything but the
kitchen sink. Sometimes, the second one never ships at all, and you
end up with product number one with a few new features as product
number two.

On the other hand, the old rule of thumb is you never want
even-numbered software releases, since the even-numbered one
breaks everything, and the odd-numbered one gets it working again.

cp/67 ... did have an intermediate ... which was cp/40 (between it and
the ctss 7094).

360/67 was official product with virtual memory hardware support.

before 360/67 was available, the csc group built special modified
virtual memory hardware for a 360/40 and built cp/40 for that machine
during 1966 (the 360/40 dat/virtual memory hardware had almost no
resemblance to the 360/67 implementation). then during 1967, it was
rewritten for 360/67 and installed on 360/67 that csc got at 545 tech
sq ... and on lincoln lab's 67s. the last week in jan. 1968, three
people came out from cambridge to install at the university i was at.

the official corporate product for 360/67, virtual memory support,
time-sharing, etc was tss/360. this was a system that started out with
extremely huge bloat (including the kitchen sink); recent tss/360
bloat reference:
http://www.garlic.com/~lynn/2003g.html#24 UltraSPARC-IIIi

above having footnote regarding unix ported on top of tss/370 (subset)
and deployed inside at&t.

and possibly the biggest bloat of all time .... which never saw the
light of day and few people are even aware of was "future system" or
"FS"
http://www.garlic.com/~lynn/subtopic.html#futuresys

the university found os/360 release 14 to be quite stable .... but
there was never a (real?) os/360 release 15 ... the next release was
called os/360 release 15/16 (aka combined release 15 and 16).

there is a bunch of stuff about ctss, multics, tss/360, cp/40, and
cp/67 (some amount was 360/67 loosing multics bid to GE):
http://www.princeton.edu/~melinda/

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

One Processor is bad?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: One Processor is bad?
Newsgroups: alt.folklore.computers
Date: Thu, 17 Apr 2003 02:17:38 GMT

Ivan writes:

VM/HPO (The High Performance Option for VM/SP) Had an interresting
approach to reduce MP induced overhead. I reckon some guy determined
that some of the overhead was generated by handling the external
interrupt used to communicate with SIGP from one CPU to another
(probably 100-200 Instructions in External FLIH & Sigp SLIH) (not
forgeting that IIRC SIGP & Interrupts both do a Checkpoint
synchronisation.. But so do CS & CDS)

from my viewpoint all the additional SIGPs went into VM/SP to
specifically handle the TPF (or possibly single-processor MVS?) type
cases in the 3081 time-frame (aka as per previous post); i.e. an
environment where there wasn't much of anything else running on the
machine but the single guest and so the second processor was spending
almost all of its time in wait state. You could gimmick the I/O
simulation by doing a SIGP to the idle processor to handle SIOF, ccw
translation, real i/o scheduling, etc ... on the idle processing while
returning to the virtual guest. This basically overlaped I/O
simulation on the idle processor with the guest running back on "its"
processor (furthermore, the idle spin loop would also be
characteristic of it being specifically targeted at such an
environment ... single, single processor, virtual guest with the 2nd
real processor nominally idle).

One could claim this in some sense the analogy of transition from
370/158 to 3031. The 158 had embedded channels, and the 158 engine was
effectively time-sliced between emulating 370 execution and performing
the io/channel function. For the 303x line, a 158 engine was taken
with the 370 emulation removed and dedicated to io/channel function
... and called a "channel director". A 3031 was basically a 158 with
two 158 engines ... one dedicated to 370 emulation and one dedicated
to io/channel function (called a channel director).

the issue was that in loaded environment ... mixed guest plus cms, cms
instensive, multiple guests, etc ... the SIGP change w/SP resulted in
the SIGP, SIGP Interrupt handling and various lock contention overhead
(as a result of the SIGPs) going from almost unmeasurable (pre-SP) to
ten percent of both processors ... which didn't actually achieve any
purpose (other than degrade thruput). There were some SHARE reports
specifically about the 10% overhead change with VM/SP ... and being
associated specifically with the SIGP changes.

Effectively, the implementation was fairly specificly targeted at the
single-processor guest with idle 2nd processor, but it wasn't
implemented in such a way that it was inactive in other environments.
One might assert that the product got hijacked by a very specific
market niche.

The pre-SP version actually had some environments where the thruput of
two processors was more than twice that of a single processor. This
had to do with some natural tendency in the implementation for cache
affinity ... and twice the cache along with improved cache hit ratio,
more than offset the various hardware and software MP overheads.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

price ov IBM virtual address box??

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: price ov IBM virtual address box??
Newsgroups: alt.folklore.computers
Date: Thu, 17 Apr 2003 02:37:38 GMT

shoppa@trailing-edge.com (Tim Shoppa) writes:

But as I understand it, this required different microcode.  Was there
any difference in speed for VM vs non-VM?  My experience is on PDP-11's,
and there if you ran without MMU you generally got a speed advantage
(varied depending on processor implementation).

oh and i forgot
http://www.garlic.com/~lynn/2000f.html#59 360 Architecture, Multics, ... was (Re: X86 ultimate CISC? No.)

discussion of virtual memory modifications to 360/40 for cp/40
... where 64 word associative array "dat box" ... didn't degrade
360/40 processing.

--
Anne & Lynn Wheeler | http://www.garlic.com/~lynn/
Internet trivia 20th anv http://www.garlic.com/~lynn/rfcietff.htm

Lisp Machines

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Lisp Machines
Newsgroups: comp.lang.scheme,comp.lang.lisp,comp.arch,alt.folklore.computers
Date: Thu, 17 Apr 2003 03:50:07 GMT

Toon Moene writes:

Yes, even the original text of the chapter "Second System Effect"
talks about "frill after frill, embellishment after embellishment".
So people usually associate "Second System Effect" with "growth".

However, the crucial sentence of this chapter is: "The general
tendency is to over-design the second sys