Martin Gregorie  wrote:
> On Sat, 10 Mar 2018 13:16:18 -0600, Michael J. Mahon wrote:
>
>> Scott Lurndal  wrote:
>>> Jack Fearnley  writes:
>>>> On Fri, 09 Mar 2018 18:29:25 +0000, Scott Lurndal wrote:
>>>>
>>>>> Dennis Lee Bieber  writes:
>>>>>> On Fri, 09 Mar 2018 17:16:19 +0100, David Brown
>>>>>> 
>>>>>> declaimed the following:
>>>>>
>>>>>> 
>>>>>>
>>>>>> There is always the convention used by Xerox Sigma Fortran-IV.
>>>>>> Non-recursive, non-stack...
>>>>>>
>>>>>> Arguments were passed by putting them immediately after the CALL
>>>>>> (branch and link opcode, and referenced by return address (saved in
>>>>>> a register; I think 15 was the standard) + index.
>>>>>
>>>>> This was very common in the 1970s.   The PDP-8 had similar parameter
>>>>> passing as did the Burroughs B2500 and descendents until the early
>>>>> 80's when a re-entrant call (Virtual Enter (VEN)) was added to the
>>>>> architecture.
>>>>>
>>>>> Unix system calls (UnixV6 on the PDP-11) embedded the system call
>>>>> arguments in the instruction stream following the system call
>>>>> instruction.
>>>>>
>>>>> The B2500 system call instruction (BCT) had the following general
>>>>> form:
>>>>>
>>>>> BCT NNNN           # NNNN selects the system call BUN +Skip # Branch
>>>>> Unconditional to after the parameters ACON label         # first
>>>>> parameter (address constant)
>>>>> DATA 2 UN 01       # second parameter, two digit numeric, value 01
>>>>> .Skip
>>>>>
>>>>> The operating system would bump the return address by the size of the
>>>>> branch instruction (8 or 10 digits) to get the parameters.
>>>>
>>>> Even further back. This was the standard method in the IBM1401 which I
>>>> was programming in 1960.
>>>
>>> The B2500 dates back to 1965, and it did have a 1401 compability mode
>>> :-)
>>>
>>>
>> Not a compatibility mode, but a software emulator (which was little used
>> by 1967).
>
> From what I've been told about the B2xxx and B3xxx mainframes by people
> who were developers on them they went a lot further than that -
> effectively providing a set of VMs for running applications in, e.g.
> Fortran programs ran in a stack-based environment with word addressed
> memory while COBOL programs ran in a (possibly) stack-free environment
> with byte-addressed memory. So, if they used VMs that way internally, it
> would seem natural if they had a 1401 VM (ant several others for other
> architecture

As one of the designers of the successors to the B2500/B3500, and one of
the “variable microcode” implementors of the B1700/B1800/B1900 line of
machines, I can tell you that you are thinking of the B1700 (small systems)
line, not the B2500 (medium systems) line.

Burroughs was a great environment for studying comparative computer
architecture, because they had so many of them! ;-)

By the time that the B1700 shipped, the IBM 1401 was no longer a
significant competitive architecture. But, you are correct that the B1700
line could have easily supported microcode (or an “S-machine”, to use
Burroughs’ parlance) to run IBM 1401 programs unchanged.

The B1700 line was an experiment in building a machine with minimal
commitments to the higher-level architectures that it would support. For
example, the memory was bit addressable, and could fetch up to 24 bits
starting at any bit!  (This microarchitecture was inspired by Bob Barton,
who also inspired the B5000 stack architecture. Bob famously pronounced,
“In the beginning was the word, and it was the wrong size.”)

In fact, of course, maximizing effective memory bandwidth is a cardinal
responsibility of any cost-effective computer architecture, so fetching
anything less that the maximum 24 bits in a memory cycle was quite
wasteful, and most language interpreters “misused” the bit addressable
memory by making such maximal accesses and parsing bit fields in microcode.


It was a great experiment which almost immediately demonstrated that bit
addressable memory was a hardware complexity that did not result in
improved efficiency.

> Me? I've never even set eyes on a Burroughs B-series mainframe. The
> nearest I came to that sort of experience was using a 2966 that ran two
> very different architectures simultaneously: George 3 and its applications
> in a single VM [word addressed RAM using 24 bit words, 6 bit ISO
> character codes, no stack]  and VME/B and its applications in a set of VMs
> [byte addressed RAM, EBCDIC character codes and a stack-based
> architecture] and two operator's consoles - one for G3 and a second for
> VME/B

There have been several “variable micrologic” computers sold. The first
that I encountered was a Raytheon machine in the early 1960s. These
machines are great vehicles for architectural experiments and perhaps have
their greatest value as platforms for emulators. But they are all less
efficient than a dedicated hardware implementation of an architecture.

In fact, the operating system of the B1700 line, which ran on its own
interpreter, was eventually speeded up significantly by compiling important
parts of it directly to the underlying microcode.

This is an excellent example of the fundamental RISC principle, which is
that for maximum cost-effectiveness, one should design simple hardware,
comparable to a vertically microprogrammed machine in complexity, and then
compile programs to the hardware level.

Some characterize RISC machines as non-microprogrammed machines, but it is
equally valid to think of them as “compile to microcode” machines. In fact,
RISC machines which exploit multiple concurrent functional units are
similar to horizontally microprogrammed machines, or
VLIW machines.

--
-michael - NadaNet 3.1 and AppleCrate II:  http://michaeljmahon.com

--- SoupGate-Win32 v1.05