The Perfect Computer - 36 bits? [Computer Architecture]

Prev: Searching for the PDP-3
Next: superscalar and superpipelined

From: jmfbahciv on 9 Apr 2007 06:58

In article <m38xd5ef5n.fsf(a)garlic.com>,
Anne & Lynn Wheeler <lynn(a)garlic.com> wrote:
>jmfbahciv(a)aol.com writes:
>> How did you ship the software if it had numbers "hardwired" in the
>> software? We had to be generic with all the specifics because
>> our customers also had multiple systems running software built
>> from the same distribution tapes.
>
>re:
>http://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36 bits?
>
>you had a (software) table of processor numbers for all known/supported
>processors at the time the product shipped ... with associated processor
>specific action/values.
>
>rather than doing a store cpuid and then a lot of code that did (inline)
>compares for a specific processor type ...

We didn't do that. The ASCII sources had feature test switches
around the CPU-specific code. Assembling and linking the code
would exclude the unwanted instrucitons.

The advantages of organizing the code this way is to remind a
developer which areas in each source file needed extra
thought, and perhaps different code. None of this was done
at runtime.

>and branch to code for that
>specific processor type ... there was a (software) table of each of the
>processor types ... do a store cpuid and then find the corresponding
>processor type in the table of processor types ... which then had
>details for what to do for processor specific handling.

The advantage of your code organization is that one EXE would
be able to run on any flavor of processor. It is the only
workable solution if customers didn't receive monitor sources
and did not routinely build their own EXEs.

>
>what i described about doing in the resource manager ... is being able
>to determine the needed processing by other characteristics ... w/o
>needing to match on processor specific cpuid. the dynamic adaptive code
>in the resource manager was supposed to dynamically adapt to things like
>workload and configuration. this allowed the resource manager to also
>dynamically adapt to processor types ... and in the case of the AT&T
>longlines example ... adapt to a decade of news processor (types) that
>were introduced for a decade after the specific code was given to
>longlines (not known at the time that specific code was generated)

That had to have been extremely clever code to admire. We didn't
have the luxury of customers who wanted to run our code as distributed.
Everybody had their own tweaks; I always thought this was a side
effect of providing a _general_ timesharing monitor. (This kind
of monitor is the complete opposite of a system dedicated to run
batch processing; I'm using IBM's definition of batch in this
sentence.)

<snip>

/BAH

From: Anne & Lynn Wheeler on 9 Apr 2007 12:02

jmfbahciv(a)aol.com writes:
> That had to have been extremely clever code to admire. We didn't
> have the luxury of customers who wanted to run our code as distributed.
> Everybody had their own tweaks; I always thought this was a side
> effect of providing a _general_ timesharing monitor. (This kind
> of monitor is the complete opposite of a system dedicated to run
> batch processing; I'm using IBM's definition of batch in this
> sentence.)

posts in this thread about processor specific source code and/or
store cpuid instruction
http://www.garlic.com/~lynn/2007g.html#54 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#55 IBM to the PCM market
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#61The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#72 The Perfect Computer - 36 bits?

cp67 and vm370 was distributed with full-source ... as well as
maintenance was distributed via source. lots of customers built system
totally from source. i've also mentioned that the share/waterloo tape
eventually had more new/changed source than the base product.
http://www.garlic.com/~lynn/2007e.html#41 IBM S/360 series operating systems history
http://www.garlic.com/~lynn/2007e.html#43 FBA rant
http://www.garlic.com/~lynn/2007g.html#9 The Perfect Computer - 36 bits?

however, complete binaries were distributed so customer could run system
w/o having to rebuild from source.

when multiprocessor support started shipping ... there was a single set
of source with optional logic generated based on whether or not
multiprocessing version was selected (so when building from source,
there was configuration option that controlled code generation with or
w/o multiprocessor support). and along with that, two different binaries
were shipped ... one with multiprocessor support and one w/o
multiprocessor support.

lots of past posts about (cp67 and later) vm370-based commercial
interactive timesharing service bureaus (like ncss, idc, tymshare, etc)
http://www.garlic.com/~lynn/subtopic.html#timeshare

and possibly the largest such operation was the internal
HONE service ... providing world-wide support for marketing, sales,
and field people
http://www.garlic.com/~lynn/subtopic.html#hone

in any case, cp67 and then vm370 was used heavily for interactive,
general timesharing.

there was some issues with tweaking the resource manager. first the
control algorithms tended to be more akin to operation research fortran
code (even tho implemented in assembler) intermixed with low-level
kernel assembler code. many of the straight kernel operating system
coders and maintaners found the code-style unfamiliar and hard to decipher
.... and would frequently make mistakes when attempting to tweak code in
and/or around resource management control. this could still cause
problems a decade or two after the distributed source code was no longer
my responsibility. various posts concerning some of the features of
the resource manager and/or dynamic adaptive control operation
http://www.garlic.com/~lynn/subtopic.html#fairshare
http://www.garlic.com/~lynn/subtopic.html#wsclock

it also contributed to my being able to ship an embedded "joke" in the
code in plain site ... that was nobody ever picked up on (even when full
logic and source was being explained in university courses) ... recent
post reference joke
http://www.garlic.com/~lynn/2007g.html#56 The Perfect Computer - 36 bits?

the other problem with the resource manager source was that it was
and "add-on" charged for software product ... the resource manager
having been selected as the guinea pig for change to start charging
for kernel software
http://www.garlic.com/~lynn/subtopic.html#unbundle

the resource manager had shipped prior to vm370 multiprocessor support
(in the base kernel) ... but I had included in the resource manager a
lot of kernel restructuring and other stuff not directly associated with
resource control (including a lot of stuff needed for multiprocessor
support). recent post touching on some of this
http://www.garlic.com/~lynn/2007g.html#17 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#44 1960s: IBM mgmt mistrust of
SLT for ICs?

the initial policy that had been worked out for kernel software charging
was that hardware/device related support would still be free ... which
obviously multiprocessor support was. The problem was that it would
then be a violation of the policy if the customer was required to
purchase the resource manager in order to get the free multiprocessor
support. the resolution was something like 80-90 percent of the code in
the (first) resource manager release was moved into the base (free)
kernel as part of releasing multiprocessor support. lots of past
posts mentioning multiprocessor and/or related items
http://www.garlic.com/~lynn/subtopic.html#smp

other stuff that went into the resource manager release was a lot of
performance testing and performance modeling ... including heavy
benchmarking as part calibration and verification of the resource
manager under lots of different conditions. part of this included
automated benchmarking procedure and APL-based performance model that
was used to "wander" the landscape of all possible combinations and do
automatic choice of what combination to be used for the next
benchmark. the final test sequence before release was 2000 benchmarks
that took 3 months elapsed time to run
http://www.garlic.com/~lynn/subtopic.html#benchmark

From: Anne & Lynn Wheeler on 9 Apr 2007 13:36

From: Anne & Lynn Wheeler on 9 Apr 2007 13:58

Anne & Lynn Wheeler <lynn(a)garlic.com> writes:
> in turn, the size of the cp67/vm370 interactive customer set was much
> larger than the size of the internal cp67/vm370 interactive customer
> set. note however, the internal network was dominated by cp67/vm370
> machines ... and was larger than the arpanet/internet from just
> about the beginning until possibly mid-85.
> http://www.garlic.com/~lynn/subnetwork.html#internalnet

re:
http://www.garlic.com/~lynn/2007g.html#73 The Perfect Computer - 36 bits?
http://www.garlic.com/~lynn/2007g.html#75 The Perfect Computer - 36 bits?

for other drift ... one of the reasons that arpanet/internet exceeded
the size of the internal network in mid-85 timeframe was internet was
adding an increasing number of workstations and PCs ad nodes ... while
the internal network remained (almost purely) mainframe (except possibly
one or two A74s ... precursor to p370/p390).

PCs saw some amount of uptake in corporate environments because of
terminal emulation support; corporation could get a PC for about the
same price as a 3270 terminal ... and have in a single desktop footprint
both 3270 terminal operation as well as some amount of local computer
(relatively easy business case to make ... if a company was already
budgeted to buy 3270 terminals ... to buy PC in its place).

this spawned a fairly large install base of terminal emulation PCs
.... and then subsequently some amount of corporate politics around
protecting the terminal install base (in the face of industry starting
to move into peer-to-peer networking and client/server technology).
http://www.garlic.com/~lynn/subnetwork.html#emulation

we ran into such corporate polictics when we were doing HSDT (high-speed
data transport) project
http://www.garlic.com/~lynn/subnetwork.html#hsdt

as well as when we were out pitching 3-tier networking architecture
and facing conflict with "SAA" (which could be construed as corporate
effort attempting to hold the terminal emulation line)
http://www.garlic.com/~lynn/subnetwork.html#3tier

there was even some interesting politics when i had done RFC 1044
support for the standard mainframe tcp/ip product. The standard product
would get about 40kbyte/sec thruput on 3090 ... consuming nearly a full
3090 processor. In some tuning work at Cray Research, we were getting
mainframe channel thruput (1mbyte/sec) between a 4341 clone and a cray
(using only a modest amount of the 4341 clone)
http://www.garlic.com/~lynn/subnetwork.html#1044

recent reference/post to some other work for HSDT thruput
http://www.garlic.com/~lynn/2007g.html#70 The Perfect Computer - 36 bits?

misc. past posts referring to A74:
http://www.garlic.com/~lynn/2000e.html#55 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2000e.html#56 Why not an IBM zSeries workstation?
http://www.garlic.com/~lynn/2001i.html#19 Very CISC Instuctions (Was: why the machine word size ...)
http://www.garlic.com/~lynn/2001i.html#51 DARPA was: Short Watson Biography
http://www.garlic.com/~lynn/2002d.html#4 IBM Mainframe at home
http://www.garlic.com/~lynn/2002l.html#27 End of Moore's law and how it can influence job market
http://www.garlic.com/~lynn/2003f.html#56 ECPS:VM DISPx instructions
http://www.garlic.com/~lynn/2003h.html#40 IBM system 370
http://www.garlic.com/~lynn/2003m.html#15 IEFBR14 Problems
http://www.garlic.com/~lynn/2004l.html#65 computer industry scenairo before the invention of the PC?
http://www.garlic.com/~lynn/2004m.html#7 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#8 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2004m.html#10 Whatever happened to IBM's VM PC software?
http://www.garlic.com/~lynn/2007c.html#14 How many 36-bit Unix ports in the old days?

From: jmfbahciv on 10 Apr 2007 07:25

In article <mddvegxj7sj.fsf(a)panix5.panix.com>,
Rich Alderson <news(a)alderson.users.panix.com> wrote:
>jmfbahciv(a)aol.com writes:
>
>> The -10 already had "segmentation" in its philosophy. You didn't run any
>> code without GETSEGing. So I don't understand how you expected an
>> enhancement to make segment boundaries invisible.
>
>STOP!

[emoticon skids to a halt and goes from c to 0 in three weeks]

>
>IRRELEVANCY ALERT!
>
>NOT THE THING BEING DISCUSSED AT ALL!

[emoticon walks back to the crossroads with head hanging in
disappointment]

>
><ahem> Now that I have your attention, please allow me to
>discourse a little on
>the two things merged like creatures in a 1950's monster film.

Yes, sir!
>
>The Tops-10 operating system has a notion, originally
>based in the hardware of
>the first PDP-10 (the 1967 KA10 processor) but divorced
>from that in all later
>processors with the same ISA, of high and low "segments" of core^Wmemory. It
>is possible to give the two segments different hardware-level protection, and
>to change the start address of the high segment (usually 400000, that is to
>say, half of the address space). As usually written, a user program has a
>sharable "high segment" and a non-sharable "low segment"; HLL runtimes, for
>example, are written to be "high segments".

Right. This was the bridge memory management implemented between
requiring all code in core (segment) when the job was executing
and paging which allowed a subset of continuous code in core
while the job was executing.

>
>(The OS, of course, maintains a table of physical starting addresses for each
>segment of each job, and relocates as is usual in any
>timesharing architecture,
>but this is not relevant to the programmer-level view of the situation.)

Right, unless the programmer coded programs too big for user mode
adresss space.
>
>Sometimes code is too large to fit in the 18-bit address space,

Or it's too big to fit after the monitor and every thing else
has been mapped into core.

> and overlays
>are necessary (as in any small-memory computer system).
>The Tops-10 innovation
>is to give explicit runtime control of what "segment" may be
>overlaid next to
>the programmer (as opposed to the OS-mediated overlays
>familiar to programmers
>on, for example, IBM 360 systems). This is done with the system call GETSEG,
>and that is what Barb is thinking of in her statement above.

Yes. It allowed the user mode program to "control" which
piece of code was called in next. But I don't call GETSEGing
overlaying. Overlaying was something that you asked LINK
to do. And not very many programs did this. Note that I never
read code that did it nor wrote code that overlayed. All
I know is the attitude of David Nixon was that using the
overlay function was similar to programmers modifying the
code during runtime. Only the most experienced and daring
big gods should do this and bit gods who have the experience
know enough not to do it.

>
>Note that neither Tops-20 nor ITS, PDP-10 operating systems
>which do not share
>code with Tops-10, has this style of overlay handling, so it is not required
>even on the PDP-10.
>
>[Note to Barb:
>
> What is meant by "segmented addressing" in the posts by others than yourself
> in this thread is an entirely unrelated notion, more
>similar to the relocation
> registers in the KA10 that allowed the development of the Tops-10 "segments"
> feature.

I interpreted those references to be somewhat, but not exactly,
similar to our final notion of section numbers.

> It is best known to most younger programmers from the early Intel
> x86 family of processors: There is a hardware register into which the
> programmer or the OS puts a segment address, and from
>that point on until the
> register is changed, all addresses in the running program
>are modified by the
> automatic addition of the segment address (left shifted
>IIRC 4 bits, to give a
> 20-bit extension to the base 16-bit address space). --rma
>]
>
>Extended addressing on the KL10 and later processors is not *precisely* a
>segmented memory architecture in the sense of the early x86's, but it shares
>enough commonality of problems that it can be lumped in with them, even if we
>call them "sections" instead of "segments".
>
>In PDP-10 extended addresses, the 18-bit address space is extended by 12 bits
>(on the KL10, only 7 implemented in hardware; on the Toad-1,
>the full 12), with
>the processor state machine (loosely, "the microcode") taking cognizance of
>whether instructions are being executed in "section 0" or a non-zero section.
>Certain instructions are relegated to "local-section-only"
>status, meaning they
>are restricted to any particular 18-bit subset of the global address space in
>which they are used: Increments from 777777 wrap to 0 rather than going to
>1000000 (which would be the next section start), and so on.
>
>Now that we have that straight...

<GRIN> I'll try to describe how I thought about all that fancy addressing
extensions...being that I am not a hardware thinking type...

Each time the guys came out with a "new" way to extend memory
ranges in user mode code, I "added" one element to my matrix.
So a KA single or double segment program, had subscripts, (x,y),
with the y having three possible states: non-existent, non-sharable
and sharable.

When paging happened, an address gained another subscript that contained
the page number. When sections happened, an address gained another
subscript.

I just know that my meager attempt at describing how I think is
going to fail. :-( But it is necessary for setting up my
next post.

/BAH

First | Prev | Next | Last
Pages: 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102
Prev: Searching for the PDP-3
Next: superscalar and superpipelined