Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #2012 > unrolled thread

History of byte addressing

Back to article view | Back to comp.arch

Contents

  History of byte addressing John Levine <johnl@iecc.com> - 2011-06-02 19:36 +0000
    Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-02 20:38 +0100
      Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 08:05 -0700
    Re: History of byte addressing Alex McDonald <blog@rivadpm.com> - 2011-06-03 05:26 -0700
      Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-03 09:48 -0400
    Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 07:49 -0700
      Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-03 10:56 -0700
    Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-04 10:59 -0700
      Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-04 15:01 -0700
        Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-04 22:53 +0100
          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:40 -0700
      Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-06-05 06:10 +0000
        Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-05 10:00 -0700
          Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-05 10:04 -0700
            Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:36 -0700
              Re: History of byte addressing "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-06-05 11:00 -0700
                Re: History of byte addressing Morten Reistad <first@last.name> - 2011-06-05 21:42 +0200
                  Re: History of byte addressing anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-06-06 17:03 +0000
                    Re: History of byte addressing Andrew Reilly <areilly---@bigpond.net.au> - 2011-06-06 23:55 +0000
                      Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:26 -0700
                        Re: History of byte addressing Andrew Reilly <areilly---@bigpond.net.au> - 2011-06-07 05:08 +0000
                          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-07 03:26 -0700
                        Re: History of byte addressing Roberto Waltman <usenet@rwaltman.com> - 2011-07-05 20:00 -0400
                          Re: History of byte addressing jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-06 00:15 +0000
                Re: History of byte addressing George Neuner <gneuner2@comcast.net> - 2011-06-05 16:18 -0400
                Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:10 -0700
                Re: History of byte addressing torbenm@diku.dk (Torben Ægidius Mogensen) - 2011-06-07 10:50 +0200
                  Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:02 +0200
                Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 15:51 +0200
              Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-05 13:43 -0600
                Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:12 -0700
                  Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-06 02:04 -0400
                    Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-05 23:49 -0700
                      Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-06 13:34 -0400
                        Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-06 10:49 -0700
                          Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-06 22:42 -0700
                            Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-07 07:37 -0400
                            Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-07 08:22 -0700
                              Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-11 09:56 -0700
                                Re: History of byte addressing EricP <ThatWouldBeTelling@thevillage.com> - 2011-06-11 14:59 -0400
                                  Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-11 18:52 -0600
                                    Re: History of byte addressing "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-06-12 12:40 -0700
                              Re: History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-11 15:05 -0400
                        Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 13:10 -0600
                        Re: History of byte addressing George Neuner <gneuner2@comcast.net> - 2011-06-06 16:41 -0400
                        Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:13 -0700
                          Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 23:50 -0600
                            Re: History of byte addressing Jim Haynes <jhaynes@alumni.uark.edu> - 2011-06-07 10:01 -0500
                              Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-07 13:09 -0600
                                Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-07 14:03 -0600
                  Re: History of byte addressing Louis Krupp <lkrupp@nospam.indra.com.invalid> - 2011-06-06 05:16 -0600
          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 10:44 -0700
          Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-06-06 05:00 +0000
            Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-05 22:11 -0700
              Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-06 08:00 +0100
                Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:16 -0700
              Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 01:01 -0700
                Re: History of byte addressing nmm1@cam.ac.uk - 2011-06-06 08:30 +0100
                  Re: History of byte addressing Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-06-06 10:34 +0200
                    Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 03:29 -0700
                      Re: History of byte addressing Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-06-06 15:21 +0200
                  Re: History of byte addressing Michael S <already5chosen@yahoo.com> - 2011-06-06 03:23 -0700
                    Re: History of byte addressing MitchAlsup <MitchAlsup@aol.com> - 2011-06-07 08:01 -0700
                  Re: alignment, was History of byte addressing John Levine <johnl@iecc.com> - 2011-06-06 18:33 +0000
                    Re: alignment, was History of byte addressing nmm1@cam.ac.uk - 2011-06-06 19:30 +0100
                      Re: alignment, was History of byte addressing Anne & Lynn Wheeler <lynn@garlic.com> - 2011-06-06 15:32 -0400
                Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-06 18:11 -0700
            Re: History of byte addressing Robert Myers <rbmyersusa@gmail.com> - 2011-06-06 06:48 -0700
              Re: History of byte addressing jsavard@excxn.aNOSPAMb.cdn.invalid (John Savard) - 2011-07-03 16:13 +0000
          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-03 09:10 -0700
    Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:23 +0200
      Re: History of byte addressing Stephen Fuld <SFuld@alumni.cmu.edu.invalid> - 2011-06-07 08:26 -0700
    Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:25 +0200
      Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:45 +0200
        Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:48 +0200
        Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 16:59 +0200
          Re: History of byte addressing "Skybuck Flying" <Windows7IsOK@DreamPC2006.com> - 2011-06-07 17:05 +0200
    Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-06-18 15:43 -0700
    Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 03:14 -0700
      Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 03:40 -0700
        Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 04:28 -0700
          Re: History of byte addressing nmm1@cam.ac.uk - 2011-07-04 13:38 +0100
            Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 06:47 -0700
              Re: History of byte addressing nmm1@cam.ac.uk - 2011-07-04 14:16 +0100
          Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:53 +0100
        Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:36 +0100
          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 07:50 -0700
            Re: History of byte addressing John Levine <johnl@iecc.com> - 2011-07-04 19:46 +0000
              Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 15:29 -0700
                Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-05 00:02 +0100
        Re: History of byte addressing Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-07-04 15:47 +0100
          Re: History of byte addressing Quadibloc <jsavard@ecn.ab.ca> - 2011-07-04 07:54 -0700

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

#2155

On Sat, 11 Jun 2011 14:59:06 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

>Andy "Krazy" Glew wrote:
>> On 6/7/2011 8:22 AM, Stephen Fuld wrote:
>>> On 6/6/2011 10:42 PM, Andy "Krazy" Glew wrote:
>>>> On 6/6/2011 10:49 AM, Stephen Fuld wrote:
>>>
>>> snip
>>>
>>>>> Not having user access to write "assembler" level code is integral to
>>>>> the security and integrity model. You see, there is no hardware "user
>>>>> mode" versus "Supervisor" or "Privileged" mode. Thus allowing user
>>>>> access to the low level stuff would allow him to compromise the system
>>>>> as he could over write the OS, other user's code, etc.
>>>>
>>>> And I believe that the problems with validating Burroughs' security
>>>> model were what led Virgil Gligor to make it a requirement that all
>>>> secure machines for US government use had to have at least
>>>> kernel/user privilege levels.
>>>
>>> While you know far more about this than I do, and you may very well be
>>> right about what the government did, that seems too simplistic. A
>>> minimal kernel/user privilege just prevents user mode programs from
>>> executing certain instructions. That is, it does not assure memory
>>> protection. For example, IBM's CICS (its major transaction system for
>>> S/370 and successors) had for a long time (and may still have) the
>>> "feature" that both the CICS monitor and all user written transactions
>>> were in a single address space. Thus a user written transaction program
>>> with a subscript gone awry could over write another user program, or
>>> even the CICS monitor. So for reasonable security, you need more than
>>> just user/kernel mode protection.
>>>
>>>
>>>> The problem with Burroughs' model is that you have to prove the compiler
>>>> and/or assembler correct.
>>>
>>> I am not sure about this. Isn't it sufficient to prove that the compiler
>>> (remember, no assembler!) doesn't emit the privileged instructions, and
>>> that the language doesn't support "dangerous" idioms, like pointer
>>> arithmetic, checks array bounds, etc? This seems much simpler than
>>> proving the compiler correct. As mentioned elsewhere in this thread,
>>> Burroughs has different versions of the compiler, one for the OS and one
>>> for users to use. Presumably the user compiler doesn't emit the
>>> privileged op codes.
>> 
>> I assume that you have at least the ability to divide memory into 
>> kernel-accessible-only and user-accessible regions, along with control 
>> of specific instructions.
>> 
>> ---
>> 
>> Now, let's progress to supposition:   Let's imagine that you have 
>> separate user and OS versions of the compiler and assembler - and that 
>> you have not simply ifdeffed them.  And let's imagine that the user 
>> tools do not emit "privileged" instructions (however, remember that 
>> there is no privilege enforced at the hardware level). And that an 
>> "OS"library is linked to the "user" code.
>> 
>> At the very least you have  to make sure that the user tools do not have 
>> any bugs in indirect branches or other control flow.  Oh, yes, and 
>> buffer overflows. And...
>
>And only languages with routine prototypes and argument type checking,
>otherwise mismatched args allow you to turn, say, an integer into an array
>descriptor. Which rules out Fortran - a pretty big market in those days.
>
>And the linker has to check that args match or no modular compilation,
>otherwise you can just link with a routine with the same name but
>different args.
>
>And stack overflow checking (if it has a stack).
>Or if there is no call stack then can recursion break the system?

Burroughs Large Systems took care of all of that.  Both the BINDER (a
seldom-used utility that linked subprograms into a single executable)
and the run-time LIBRARY facility checked arguments thoroughly.  With
Burroughs' memory model, everyone shared the same address space, and
if you could, say, index past the end of an array, you could read or
write data that belonged to another user.  So arrays were (and still
are) indexed through descriptors that contained the array length.
Index too far, and the program got an "INVALID INDEX" fault.

There was nothing to rule out a FORTRAN compiler;  Burroughs sold one
of those.  My guess is that arguments were passed by reference, so  a
scalar would look like an array of length 1 or something.  If
Burroughs didn't sell a lot of FORTRAN compilers, it wasn't because
they didn't exist or because they were a security risk;  it was
because Burroughs spent more time and energy on ALGOL.  And ALGOL may
have fit the architecture a little better than some other languages.

These systems had stacks, too;  in fact everything was done on the
stack.  Want to add two numbers?  Push one and then the other on the
stack, execute the ADD operator, and pop the sum off the top of the
stack.  There were registers for the top and bottom of the stack;  try
to push or pop too much and you get a "STACK OVERFLOW" or (if I recall
correctly) a "STACK UNDERFLOW" fault.

In about 1977, Burroughs had some of these systems at the National
Security Agency.  I know because Burroughs wanted to move me there.
For various reasons, I didn't go.

I'd like to know why these systems were judged insecure.

Louis

[toc] | [prev] | [next] | [standalone]

#2172

On 6/11/2011 5:52 PM, Louis Krupp wrote:
> On Sat, 11 Jun 2011 14:59:06 -0400, EricP
> <ThatWouldBeTelling@thevillage.com>  wrote:
>
>> Andy "Krazy" Glew wrote:
>>>>> The problem with Burroughs' model is that you have to prove the compiler
>>>>> and/or assembler correct.

> In about 1977, Burroughs had some of these systems at the National
> Security Agency.  I know because Burroughs wanted to move me there.
> For various reasons, I didn't go.
>
> I'd like to know why these systems were judged insecure.
>
> Louis
>



I believe  that the paper I am referring to is:

V. Gligor.
Hardware Selection and Evaluation Guidelines for Trusted Computer Systems.
Draft , Dept. of Electrical Engineerings, University of Maryland,
November, 1984.

Last time I googled this I was able to find a scanned version online.  I 
haven't been able to this time.

However, Prof. Gligor is still around, I believe.

---

By the way, for the Burroughs folk:  Blaine Gaither may have been the 
guy who referred me to this paper.

[toc] | [prev] | [next] | [standalone]

#2151

Stephen Fuld <SFuld@alumni.cmu.edu.invalid> writes:
> While you know far more about this than I do, and you may very well be
> right about what the government did, that seems too simplistic.  A
> minimal kernel/user privilege just prevents user mode programs from
> executing certain instructions.  That is, it does not assure memory
> protection.  For example, IBM's CICS (its major transaction system for
> S/370 and successors) had for a long time (and may still have) the
> "feature" that both the CICS monitor and all user written transactions
> were in a single address space.  Thus a user written transaction
> program with a subscript gone awry could over write another user
> program, or even the CICS monitor.  So for reasonable security, you
> need more than just user/kernel mode protection.

when undergraduate at univ., the univ. library got a ONR grant to do
online catalog; part of the money went to get a 2321 (data cell). the
effort was also selected to be betatest for original CICS product ...
and I got tasked to support/debug CICS in the effort ... some past
posts
http://www.garlic.com/~lynn/submain.html#cics

CICS had originally been developed at customer account ... and then went
through some amount of effort to productize it. ordinary OS/360 was real
memory (single address space) with enormous overhead related to
scheduling, task switch, file open/close ... just about every systeme
function. CICS (as did quite a few other "online" environments for
os/360) would go thru all the high-overhead operations at startup
... and then appear like a continuously running, single large task to
os/360 ... while implementing a lot of fine-grain light-weight monitor
functions internally.

Note that 360 in addition to single (real) address space did provide 2k
granularity fetch&storage protection. Besides the problem/supervisor
state flag in the PSW ... each 2k storage block could have a 4bit
"protect" key (for store protect as standard, 360 had optional "fetch
protect" feature ... which could provide fetch protect in addition to
store-protect). The PSW (changing was a supervisor/privilege operation)
would have 4 bit key ... which needed to match the 2kblock 4bit key for
storage operation to succeed (PSW key 0 allowed privilege bypass
store/fetch protect). This was mainly used to protect os/360 from
applications and keep applications separated (allowing up to 15
concurrent applications). However, since CICS appeared as single large
application, there wasn't any use of intra-CICS key protect.

However, CICS applications tended to be very small and light-weight and
underwent extensive testing and review before being allowed to run in
production environment. CICS was one of the multithreaded application
environments that could leverage the compare&swap instruction
... recently mentioned:
http://www.garlic.com/~lynn/2011g.html#79 alignment, was History of byte addressing
other posts mentioning compare&swap and/or smp
http://www.garlic.com/~lynn/subtopic.html#smp

while 370 introduced virtual memory, the single address space heritage
and pointer-passing API was so deeply ingrained that the MVS operating
system (separate address space for every application) continued to have
an image of the operating system occupying every virtual address space
(which also perpetuated the need for the storage key protection). Also
from OS/360 heritage there were some number of "subsystem" services that
resided outside the kernel proper. In the transition to MVS, these
subsystems were moved their individual private address space (also
having an image of the kernel proper). This created major problem with
"normal" applications making a subsystem call using pointer-passing API
(since they now occupied different address spaces). The solution was
something called the "common segment" ... an image which appeared in
every address space (akin to kernel image in every address space)
... however the size of the common segment needed to be somewhat
proportional to the number of subsystems and the number of concurrent
applications using those subsystems. Towards the end of the 370 period
(while still 24bit addressing and before 31bit addressing) ... each
application 16mbyte virtual address space would have an 8mbyte image of
the kernel and for large installations, common segments that ran
4-5mbytes (threatening to grow to 5-6mbytes); aka some installations
were being faced with limiting application size (including things like
total CICS) to 2mbytes.

The follow-on architecture would have "access registers" & program call
... basically an infrastructure of MVS "system tables" which support
application pointer-passing API call directly to a subsysetm function in
another virtual address space. The tables would allow hardware to swap
virtual address space pointers (... nearly identical to call to library
function in the same address space). The subsystem would have secondary
address space pointer back to calling application to directly access
parameters (from the pointer passing API), return results in the
application address space and do a (hardware) program return (restoring
caller's address space).

The CICS workaround to address space limitation and lack of system
multi-threading (i.e. purely internal multi-threading but appearing as
single large task to the system) ... so only ran as a single process on
a single processor ... installations would run multiple concurrent CICS
"regions". In the early part of this century, it wasn't unusual to find
some large installations with over 100 concurrently running CICS regions
(in independent virtual address space, each doing their own independent
multithreaded support).

CICS system level multithreading operation didn't appear until 2004
(i.e. single CICS address space running threads concurrently on multiple
processors). Major CICS history site has gone 404 ... but lives on at
the wayback machine
http://web.archive.org/web/20050409124902/www.yelavich.com/cicshist.htm

The Evolution of CICS: CICS and Multiprocessor Exploitation (2004)
http://web.archive.org/web/20041023110006/http://www.yelavich.com/history/ev200402.htm

from above:

CICS chose to provide for a multi-tasking environment under a single
Task Control Block (TCB) using its own dispatcher (Task Control Program)
rather than attempt to multi-task concurrent transaction processing
using operating system subtasks. Not only was the overhead of operating
system subtasking considered excessive, but having concurrently
dispatched applications would have required programs to be reentrant and
serialize their use of shared resources. That was felt to be too
complicated at the time.

... snip ...

-- 
virtualization experience starting Jan1968, online at home since Mar1970

[toc] | [prev] | [next] | [standalone]

#2065

On Mon, 06 Jun 2011 13:34:19 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

>Stephen Fuld wrote:
>> On 6/5/2011 11:04 PM, EricP wrote:
>>> Quadibloc wrote:
>>>> On Jun 5, 1:43 pm, Louis Krupp <lkr...@nospam.indra.com.invalid>
>>>> wrote:
>>>>
>>>>> That came in the early 60s with the Burroughs B5000 series. There was
>>>>> no assembler as such. Users programmed in Burroughs Extended ALGOL
>>>>> (or FORTRAN or COBOL), while the OS (the "Master Control Program") was
>>>>> written in ESPOL, which provided escapes to machine language.
>>>>>
>>>>> B6700 series (late 60s) ESPOL dropped the direct escape to machine
>>>>> language, if I recall correctly.
>>>>
>>>> Burroughs machines were a *very* special case. Not allowing people to
>>>> program in assembly language was required for _security_ on those
>>>> machines.
>>>>
>>>> John Savard
>>>
>>> What's to stop you from writing your own assembler in Fortran?
>> 
>> The only programs that are allowed to make a file executable are the 
>> ones supplied by Burroughs.  Their security model is very alien to 
>> people used to anyone else's security model.
>> 
>> 
>>> They would have to make the exe file format secret and maybe ban
>>> disassemblers or something. A policy that sounds ripe for hacking.
>> 
>> No, they are not secret, so you can know about them, and even write a 
>> program that looks exactly like an executable, but you can't get it 
>> executed.
>
>Fine, so I write my assembler in Fortran and generate the proto-exe file.
>Then I write another program in Fortran that copies files to tape
>using a raw data format that mimics the backup file format,
>but sets the magic bits in the file meta data marking it as an exe.
>Then I copy my assembler to tape, now with its proper meta header,
>back it down to disk, and Bob's Your Uncle I have my assembler.
>
>Refusing to sell the customer an assembler if that's what
>they want is a silly autocratic control freak attitude.
>After all, it is the customer's computer.

There was no assembler to sell, and in 15 years or so of working with
Burroughs computers (including time spent working for Burroughs), I
never met anyone who expressed an interest in having one.

The B5500, which preceded the Large Systems series, had a more
primitive architecture and security model. Words with the "flag bit"
(then called bit 0) set, such as descriptors and memory links, were
protected.  ALGOL implemented low-level character manipulation with
"stream procedures."  With their own arcane syntax, and with no regard
for flag bits, stream procedures were lots of fun.

It was possible to write a function that did nothing interesting, find
its address, write other machine instructions to it, and then call the
function.  One could (and I did) crash the system easily;  when the
MCP ("Master Control Program," the OS) detected a bad memory link, it
took this action:

	DO UNTIL FALSE;

Crashing the system was properly viewed as anti-social, and I tried to
limit my experiments to early mornings when I could coordinate with
the operators and make sure no one else would be impacted.  As far as
it being "the customer's computer," remember that this wasn't a PC, it
was a mainframe with mixed time sharing and batch, and as far as
Burroughs was concerned, the customer was computing center management,
and they were interested in security, stability and throughput (a word
you don't hear much these days) more than in programming fun.

Stream procedures went away with the advent of true Large Systems.
There was even a transitional B5500 ALGOL compiler, if I recall
correctly, that didn't have them.

Burroughs made lots of marketing mistakes, but refusal to write or
sell a Large Systems assembler wasn't one of them.

Louis

[toc] | [prev] | [next] | [standalone]

#2067

On Mon, 06 Jun 2011 13:34:19 -0400, EricP
<ThatWouldBeTelling@thevillage.com> wrote:

>
>Refusing to sell the customer an assembler if that's what
>they want is a silly autocratic control freak attitude.
>After all, it is the customer's computer.

Well ... no.  At the time most big iron was leased and so too was much
or all of the software.  So in many cases it /wasn't/ the "customer's"
computer.

George

[toc] | [prev] | [next] | [standalone]

#2070

On Jun 6, 11:34 am, EricP <ThatWouldBeTell...@thevillage.com> wrote:

> Fine, so I write my assembler in Fortran and generate the proto-exe file.
> Then I write another program in Fortran that copies files to tape
> using a raw data format that mimics the backup file format,
> but sets the magic bits in the file meta data marking it as an exe.
> Then I copy my assembler to tape, now with its proper meta header,
> back it down to disk, and Bob's Your Uncle I have my assembler.

In many Burroughs installations, only trusted people could bring in
tapes to be read.

John Savard

[toc] | [prev] | [next] | [standalone]

#2075

On Mon, 6 Jun 2011 18:13:03 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Jun 6, 11:34 am, EricP <ThatWouldBeTell...@thevillage.com> wrote:
>
>> Fine, so I write my assembler in Fortran and generate the proto-exe file.
>> Then I write another program in Fortran that copies files to tape
>> using a raw data format that mimics the backup file format,
>> but sets the magic bits in the file meta data marking it as an exe.
>> Then I copy my assembler to tape, now with its proper meta header,
>> back it down to disk, and Bob's Your Uncle I have my assembler.
>
>In many Burroughs installations, only trusted people could bring in
>tapes to be read.

And the potentially dangerous tapes were those in the backup ("library
maintenance") format, which included the aforementioned metadata. They
had to be read with the COPY command and wouldn't have been
intelligible to a normal user program.

The library maintenance format was arcane.  See the LEIBNITZ routine
at line 54000000 of a really old MCP listing for details.

Plain vanilla data tapes, labeled or not, were OK.  The COPY command
wouldn't know what to do with them, but it was usually easy enough to
write a program to read them given the record size and blocking factor
and so on.  Burroughs systems did automatic media label recognition --
program tries to open a tape file by name, operator mounts it on any
drive, system assigns the drive to the file, program proceeds -- and
reading the tape went pretty much like it did with every other
computer in the world.

I worked at a university that had Burroughs equipment.  I don't recall
anyone coming in from another Burroughs installation with a library
maintenance tape.  If anyone had, you're right:  we would have been
suspicious.

Louis

[toc] | [prev] | [next] | [standalone]

#2092

On 2011-06-07, Louis Krupp <lkrupp@nospam.indra.com.invalid> wrote:
> I worked at a university that had Burroughs equipment.  I don't recall
> anyone coming in from another Burroughs installation with a library
> maintenance tape.  If anyone had, you're right:  we would have been
> suspicious.
>
Seems like I remember that there was also a console activity required to
install a compiler from tape, where a compiler is a program that is
trusted to generate machine code.

[toc] | [prev] | [next] | [standalone]

#2100

On Tue, 07 Jun 2011 10:01:02 -0500, Jim Haynes
<jhaynes@alumni.uark.edu> wrote:

>On 2011-06-07, Louis Krupp <lkrupp@nospam.indra.com.invalid> wrote:
>> I worked at a university that had Burroughs equipment.  I don't recall
>> anyone coming in from another Burroughs installation with a library
>> maintenance tape.  If anyone had, you're right:  we would have been
>> suspicious.
>>
>Seems like I remember that there was also a console activity required to
>install a compiler from tape, where a compiler is a program that is
>trusted to generate machine code.

You could copy a compiler from a library maintenance tape.  Of course,
to replace, say, SYSTEM/ALGOL with something else, or to copy, say,
SYSTEM/FRED from tape, you'd have to be at a system console or you'd
have to be a priviledged user.

What I think you're thinking of is the operator command that had to be
done (from the console or by a priviledged user) to make a newly built
program a compiler.  After a new SYSTEM/ALGOL was compiled, someone
had to do something like "MC SYSTEM/ALGOL" (MC stood for "Make
Compiled") to change the FILEKIND of SYSTEM/ALGOL from ALGOLCODE
(remember, the ALGOL compiler was, and probably still is, written in
ALGOL) to COMPILERCODE.  A file marked COMPILERCODE could write an
executable file and make *its* FILEKIND ALGOLCODE or FORTRANCODE or
whatever.  The system wouldn't execute a file unless its FILEKIND was
<something>CODE.

(In case you're wondering, there was an equivalent of a link editor,
the BINDER, but it wasn't used much.  In about 1980, Burroughs
introduced the "LIBRARY" feature, which did run-time linking.)

Louis

[toc] | [prev] | [next] | [standalone]

#2101

On Tue, 07 Jun 2011 13:09:52 -0600, Louis Krupp
<lkrupp@nospam.indra.com.invalid> wrote:

<snip>
> After a new SYSTEM/ALGOL was compiled, someone
>had to do something like "MC SYSTEM/ALGOL" (MC stood for "Make
>Compiled") to change the FILEKIND of SYSTEM/ALGOL from ALGOLCODE
>... COMPILERCODE.

MC = "Make Compiler"

Louis

[toc] | [prev] | [next] | [standalone]

#2057

On Sun, 5 Jun 2011 22:12:37 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

>On Jun 5, 1:43 pm, Louis Krupp <lkr...@nospam.indra.com.invalid>
>wrote:
>
>> That came in the early 60s with the Burroughs B5000 series.  There was
>> no assembler as such.  Users programmed in Burroughs Extended ALGOL
>> (or FORTRAN or COBOL), while the OS (the "Master Control Program") was
>> written in ESPOL, which provided escapes to machine language.
>>
>> B6700 series (late 60s) ESPOL dropped the direct escape to machine
>> language, if I recall correctly.
>
>Burroughs machines were a *very* special case. Not allowing people to
>program in assembly language was required for _security_ on those
>machines.

There's a bit more to it than that.  As you mentioned in a previous
post, C was what let people move away from assembler, and Burroughs
Extended ALGOL exploited Burroughs architecture more or less like C
did with the PDP.  One difference is that Burroughs designed the
architecture and the language extensions to work together.

I don't know of any ALGOL programmers who would have wanted to write
at a lower level even if they'd understood the instruction set.  The
combination of the capability architecture and the stack made it what
you accurately described as a special case.

C bears a resemblance to ALGOL.  I don't think that's a coincidence.
The folks who designed ALGOL got a lot of things right.

(And keep in mind that this architecture is still alive and well and
being sold by Unisys as the "MCP Series" or whatever they're calling
this week.)

Louis

[toc] | [prev] | [next] | [standalone]

#2040

On Jun 5, 11:00 am, Robert Myers <rbmyers...@gmail.com> wrote:

> Goodbye IBM == Goodbye incomprehensible alignment error messages.

But you wouldn't start a 12-bit integer on a PDP-8 halfway through the
middle of a 12-bit word. So what's unnatural about being required to
start a 32-bit integer at the beginning of a 32-bit word?

The fact that the IBM 360 kindly allows you to directly address the
first half and the second half of such a word as 16-bit short
integers, or each of its quarters as 8-bit characters shouldn't change
that.

Of course, I suppose it is odd in a way that the 360 forced people to
pretend they were working on a machine with a 64-bit word and a 64-bit
memory bus, even if they were using a smaller model with an 8-bit word
and an 8-bit memory bus, but ensuring compatibility made sense - and
there were convenient alignment directives in the assembler language.

The 370 didn't have this problem - it handled unaligned operands, but
such carelessness would make a program run more slowly.

John Savard

[toc] | [prev] | [next] | [standalone]

#2045

>My history of the subject:
>
>Goodbye IBM == Goodbye incomprehensible alignment error messages.  I
>suppose I should be grateful the arithmetic wasn't all decimal.

You must have said goodbye a long time ago.  IBM mainframes haven't
required aligned operands for almost 40 years.

R's,
John

[toc] | [prev] | [next] | [standalone]

#2047

On Jun 5, 11:00 pm, John Levine <jo...@iecc.com> wrote:
> >My history of the subject:
>
> >Goodbye IBM == Goodbye incomprehensible alignment error messages.  I
> >suppose I should be grateful the arithmetic wasn't all decimal.
>
> You must have said goodbye a long time ago.  IBM mainframes haven't
> required aligned operands for almost 40 years.

Yes, that was true with the 370. But unaligned operands are still
inefficient.

John Savard

[toc] | [prev] | [next] | [standalone]

#2051

In article <5e791bb1-4b40-410c-b4bb-b0944f9168ff@z33g2000yqb.googlegroups.com>,
Quadibloc  <jsavard@ecn.ab.ca> wrote:
>On Jun 5, 11:00=A0pm, John Levine <jo...@iecc.com> wrote:
>> >My history of the subject:
>>
>> >Goodbye IBM == Goodbye incomprehensible alignment error messages.
>
>> >suppose I should be grateful the arithmetic wasn't all decimal.
>>
>> You must have said goodbye a long time ago.  IBM mainframes haven't
>> required aligned operands for almost 40 years.
>
>Yes, that was true with the 370. But unaligned operands are still
>inefficient.

It wasn't QUITE that simple!  Even on the 370s, there were some
things that required aligned operands, though most were pretty
obscure.  If I recall, they were required for the vector extensions
that came later.

But they came back with a LOT of later architectures - most of the
RISC systems started off with them, and Intel reintroduced them
at least once with its 'vector' units.  They are also there with
a truly EVIL gotcha when its comes to shared-memory parallelism.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#2071

On Jun 6, 1:00 am, n...@cam.ac.uk wrote:

> It wasn't QUITE that simple!  Even on the 370s, there were some
> things that required aligned operands, though most were pretty
> obscure.  If I recall, they were required for the vector extensions
> that came later.

I'm not surprised that they would be required for the vector
extensions. Which seem to have been kept around in some 390 models,
but the z/Architecture finally dropped the feature - because the
machines are sold at premium prices to run high-quality database
software, so no one uses them for scientific computing.

And they would have to make an extra set of vector instructions for
"binary floating point"... unless they actually did already do that.

John Savard

[toc] | [prev] | [next] | [standalone]

#2052

On Jun 6, 7:11 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
>
>  But unaligned operands are still inefficient.
>

How do you know? Did you run relevant microbenchmarks on modern IBM
hardware?

[toc] | [prev] | [next] | [standalone]

#2053

In article <93eabd84-42a3-4f74-a96c-cc28e4dce421@v10g2000yqn.googlegroups.com>,
Michael S  <already5chosen@yahoo.com> wrote:
>On Jun 6, 7:11=A0am, Quadibloc <jsav...@ecn.ab.ca> wrote:
>>
>>  But unaligned operands are still inefficient.
>
>How do you know? Did you run relevant microbenchmarks on modern IBM
>hardware?

Sigh.  Do you know how caches and TLBs work?  The inefficiency is
almost certainly vastly less than it was in the 1970s, but there
is an INHERENT inefficiency with unaligned working on machines
that use fixed alignment caching.

Even today, one of the golden rules of performance programming is
to align data.  It may help a lot or negligibly, but it is always
worthwhile and doesn't need expensive investigation and machine-
dependent hacks.


Regards,
Nick Maclaren.

[toc] | [prev] | [next] | [standalone]

#2054

nmm1@cam.ac.uk wrote:
> Even today, one of the golden rules of performance programming is
> to align data.  It may help a lot or negligibly, but it is always
> worthwhile and doesn't need expensive investigation and machine-
> dependent hacks.

True.

The corrolary to that rule is that you should order your variables so 
that they pack together naturally, with no need for alignment padding.

Some (good) compilers would do this automatically, and I have even seen 
a 16-bit compiler that would pack two 8-bit variables together and make 
a single assignment to initialize both of them.

Terje

-- 
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

#2056

On Jun 6, 10:34 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
> n...@cam.ac.uk wrote:
> > Even today, one of the golden rules of performance programming is
> > to align data.  It may help a lot or negligibly, but it is always
> > worthwhile and doesn't need expensive investigation and machine-
> > dependent hacks.
>
> True.
>

Terje, you are the last person from which I'd expect this sort of
response.
Getting old?

> The corrolary to that rule is that you should order your variables so
> that they pack together naturally, with no need for alignment padding.
>

That's another matter.
"Free" alignment could be applied without thinking twice.
On the other hand, padding should be evaluated in specific context.
That is, if performance matter. If it does not, which is a majority of
cases, I am all for think-less padding, especially in the structures
that are exposed to the outside word.

> Some (good) compilers would do this automatically, and I have even seen
> a 16-bit compiler that would pack two 8-bit variables together and make
> a single assignment to initialize both of them.
>
> Terje
>
> --
> - <Terje.Mathisen at tmsw.no>
> "almost all programming can be viewed as an exercise in caching"

[toc] | [prev] | [next] | [standalone]

Page 3 of 5 — ← Prev page 1 2 [3] 4 5  Next page →

Back to top | Article view | comp.arch

csiph-web