Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!necntc!drilex!dricej
From: dricej@drilex.UUCP (Craig Jackson)
Newsgroups: comp.arch
Subject: Re: stack machines (Burroughs)
Message-ID: <588@drilex.UUCP>
Date: 15 Jun 88 20:36:22 GMT
References: <1521@pt.cs.cmu.edu> <1532@pt.cs.cmu.edu> <476@pcrat.UUCP> <2868@louie.udel.EDU> <370@dlscg1.UUCP> <3147@polyslo.UUCP> <3693@saturn.ucsc.edu>
Reply-To: dricej@drilex.UUCP (Craig Jackson)
Organization: Data Resources/McGraw-Hill, Lexington, MA
Lines: 89

In article <3693@saturn.ucsc.edu> haynes@ucscc.UCSC.EDU (Jim Haynes) writes:
>>people wanted that to become a variable sector size, and that is what is
>>going to take them so long to implement.  Not exactly modualar software.
>
>Gee, seems like only yesterday that IBM had just discovered the
>merits of fixed sector size, after Burroughs and DEC had been using
>it all these years.  All the times that users have had to completely
>re-format their files after some new model IBM disk replaces an
>older one...  But maybe you're talking about something different.

I suspect that what the author was talking about was being able to
configure the sector size of a disk.  Sort of like setting the blocksize
of file system.  The present A-series MCP must have its disk formatted into
180-byte sectors; not 360, not 720.  This information is known all over the
place, including any well-written application.  (One wants one's blocks to
be an integral number of sectors long, for example.)

There was an interesting comparision between VM, MVS, and MCP which came
up when we were doing a procurement last year.  VM wastes disk because it
is pre-allocated to each user, and the free space cannot be shared.  MVS
wastes disk because nearly all datasets are pre-allocated, period.  MCP
wastes disk because of the ridiculously small sector size.  It came out
a wash.

Of course, Unix doesn't waste much disk, but takes *forever* to get to
it (in mainframe terms), due to the block-level allocation and all the
indirection.

>>  Algol 68 does support Data structures.  And most smart companies have

>>upgraded their systems to Algol 68 or beyond.  Why Unisys hasn't, I don't know.
>
>Errr, which companies do you have in mind?  I don't pretend to be a
>walking catalog, but I haven't heard anyone mention Algol68 in the last
>15 years or so, much less try to sell me a compiler for it.

The original author was way off-base on this one.  Algol 60 and Algol 68
share little except for a name.  Algol 68 is certainly not a simple upgrade
from 60--it's a completely different language.

>>  Even Unisys is moving towards knowing Machine code, they have a new 
>>piece of software called DumpAnalyser, they seemed to feel the need to spend
>>three weeks teaching me how to use it {they do this for all new employee's}.
>>And if you think what it puts out is Algol code you are sadly mistaken, it's
>>basicly for "reading" the stack of a program, and if that's not machine code
>
>Gee, back in B5500 days we had a dump analyzer that would print out the
>stack and various MCP tables so you could almost read it.  In contrast
>to certain other machines of the same period that would just give you
>pages and pages of pure hexadecimal in neat columns, but you had to
>figure out yourself where the structures were.  Or buy a third-party
>dump formatter for lots of money.  But that was just for use with
>MCP dumps.  For user programs you never needed dumps because the
>abort message told you exactly where to look in the program listing
>and gave you the reason for the abort in English.  I guess things have
>gone downhill since then.

The Dump Analyzer printed the object code because frequently during
systems debugging you need to know exactly which part of an expression
caused the problem.  This might be more important on the A-series than
on simple linear-address machines, because the hardware concepts were
so close to the applications language.

This portion of the architecture actually makes certain forms of 
debugging very nice.  The user-level dump facility on the A-series
is the nicest I've ever seen.  (On the latest release, they even
add symbolic variable-name information.  Sure, many debuggers have
offered this in the past, but how many dumps?)  What makes this possible
are the very things which the RISC people dislike: applications complexity
built into the hardware.  The tagged architecture allows the dump to
automatically know about data types; the descriptor-based architecture 
allows the dump to know more about the size and nature of each array; and
the stack-based architecture, with hardware support for block-structure,
makes call histories and variable addressing very easy.

(The above paragraph is my concession to architectural discussion.)

You may believe that good debuggers make dumps unnecessary, but I've found
that most bugs significant bugs occur in a production environment, and
the important thing to do in that environment is to capture information
(a dump, or a core file) and get the user back on the air somehow as soon
as possible.

>haynes@ucscc.ucsc.edu


-- 
Craig Jackson
UUCP: {harvard!axiom,linus!axiom,ll-xn}!drilex!dricej
BIX:  cjackson