🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.unisys
Article #92

Re: Info about A Serie

#92
From: Bob Hale
Date: Tue, 13 Oct 1992 19:32
120 lines
6480 bytes
In article <1992Oct13.015615.24672@syacus.acus.oz.au> ian@syacus.acus.oz.au (Ian Joyner) writes:
>
>To find out about the A Series architecture, you need to get the "A
>Series Architecture Manual" volume 2. This gives you all the machine
>instructions, and other architectural details for the whole range.
>The architecture is also known as EMode architecture. There are
>several (compatible) levels of this, alpha, beta and gamma.

The different Emode levels are not fully compatible.  Three levels
exist because of the incompatibility.  It is possible to transition
from alpha to beta, and later from beta to gamma.  You cannot mix
alpha and gamma, at least not without obtaining "unpredictable
results".

>However, you probably don't want to concentrate on the differences
>between these, as they are small. The answer to the question of
>assembler can be put in several ways. "What's assembler" is one
>answer you will get from an A Series person. Another is that the
>assembler is Burroughs Extended ALGOL. All systems software is
>written in a variant of Algol.

The MCP (operating system) and many of its supporting libraries are
written in NEWP which is a language similar to Algol but which
offers direct access to critical machine resources.  Much of the
other system software is written in languages which are appropriate
to the task - e.g., the Algol compiler is written in Algol.

You can do *almost* anything you want in NEWP, but even NEWP has its
limitations.  For example, you cannot insert a NOP after a STOD if
you need one.  This is the reason why I wrote an assembler for the
large systems.

> The machine architecture is therefore
>a run time environment for Algol.

More or less true.

> The basis of the architecture is
>a hardware stack.

Actually, the architecture is based on numerous stacks.  Generally,
each task will have one code stack and one data stack.  The use of
libraries will increase the number of stacks associated with a task.
When I last looked, the machines could handle up to 4096 stacks.

> The stack frames a referenced by a set of registers
>called D registers. There are no user accessible registers in the
>machine, the top of stack being the equivalent of registers.

There are several user-accessible registers in the machine.  For
example, the time since halt load register.  However, these are
not general-purpose registers, and if you are not programming in
NEWP or assembler these registers are not directly available to you;
you must ask the MCP for the data in them.  Since the architecture is
stack oriented there is no need for registers in the usual sense.

>The other interesting part of the architecture is that it is tag based.
>Each word in memory has an associated tag which gives the type of
>the word. Odd tags are read only words.

Odd tags indicate that the contents of the memory may not be accessed
as normal data.  They do not distinguish whether a word is read-only;
a separate bit in the descriptor indicates read-only status.  And
even a read-only word can be written to with the overwrite instruction.
Odd tags are used for a variety of purposes - e.g., the start and
end of arrays in memory, data descriptors, instruction words, IRWs, PCWs.
Attempting to access an odd tagged word as data for either reading or
writing causes a hardware interrupt.

> These [odd tags] apply to code words, which
>cannot be modified by a user program.

Perhaps we have a different definition of "user program".  A NEWP
program can easily modify a machine instruction word.  This is not
to say that I recommend that you do this, but it is possible.

> Tag 0 words are data, and tag
>2 words (even), are double precision.
>
>There are also instructions and features that help in the implementation
>of languages such as COBOL. These languages do a lot of string processing,
>so there are instructions for this. This maps to the REPLACE and SCAN
>statements of Algol, which are very powerful for compiler writing.
>
>Another interesting feature is that the architecture is descriptor
>based. Descriptors hold metadata about memory blocks, ie the address
>of a master descriptor, which holds the address of the actual block
>(this makes relocation, deallocation and overlaying easy), the length
>of the block, and the type of the block.

This is approximately true for a non-indexed data descriptor.  The mom
descriptor does hold all of this data; when the data is used then a
copy descriptor is made and placed on the stack.  This copy descriptor
can then be used to access the desired data.  Once the descriptor
has been indexed it then points to a particular data element and it
is no longer a copy of the mom.

> This makes A Series programs
>quite easy to debug, as any invalid indexes, or pointer overflows to
>a block are caught immediately, not at some later time, when the
>real error has been obscured.
>
>The architecture for the machines also ensures object code compatibility
>over a very wide range of processors from the micro A (a single chip
>processor that plugs into a PC), through to the A19. This represents
>a scalability factor of about 420 times.

A good introduction to the Burroughs architecture can be found in
the book "Computer System Architecture [Organization?]" by Organick.
Things have changed a little since he wrote the book but the principles
are still the same.  The greatest difference is that memory accesses
are now done indirectly and automatically by the hardware using a
concept called Actual Segment Descriptors.  This overcomes the
1 megaword memory size limitation.

It's a very interesting and powerful architecture.  Too bad that it
didn't capture a larger market share.

Bob Hale                                      ...!ucsd!btree!hale
...!btree!hale@ucsd.edu                       ...!ucsd!btree!hale@uunet.uu.net
Technical Details
Message-ID: <1992Oct13.193232.15867@btree.uucp>
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsk!cbnewsj!att-out!pacbell.com!network.ucsd.edu!btree!hale
References: <1992Oct7.154451.2269@tolten.puc.cl> <1992Oct13.015615.24672@syacus.acus.oz.au>

Show Full Headers
Complete Article Headers
Newsgroups: comp.sys.unisys
Path: arc1-ca.pugleaf.net!sparky!uunet!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!cbnewsk!cbnewsj!att-out!pacbell.com!network.ucsd.edu!btree!hale
From: hale@btree.uucp (Bob Hale)
Message-ID: <1992Oct13.193232.15867@btree.uucp>
Date: Tue, 13 Oct 92 19:32:32 GMT
Organization: Brooktree Corporation
Subject: Re: Info about A Serie
References: <1992Oct7.154451.2269@tolten.puc.cl> <1992Oct13.015615.24672@syacus.acus.oz.au>
Distribution: world
Organization: Brooktree Corporation, San Diego
Lines: 122