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 2 of 5 — ← Prev page 1 [2] 3 4 5  Next page →

#2073

On Mon, 06 Jun 2011 18:26:06 -0700, Quadibloc wrote:

> But trying to explain a *little-endian* computer... now, that would just
> be _too_ confusing, because now it breaks the paradigm of "writing text
> and numbers in the computer's memory, like you would on a piece of
> paper", instead of just bending it - "the computer uses shorthand for
> numbers, and counts with sixteen fingers".

I don't know: that seems exactly where little-endian would help, because 
when you are computing character at-a-time you almost certainly have 
different-length strings of digits, and we know that you want to add 
those by starting with the least-significant digit of each string.  With 
big-endian you have the extra step of first having to figure out where 
the least significant digit is.

Presumably in the days where "introduction to programming" implied IBM 
1401 or IBM 705 then it also implied fixed-width fields and implicit 
leading zeros, so perhaps it wasn't as complicated as I suggested.

By the time I'd started the "beginner's introduction to computers" 
involved interpreted basic, so endianness didn't matter until I'd pushed 
through to assembly language.

These days a "beginner's introduction to computers" probably involves 
excel and word and web-browsing, if you're lucky...

Cheers,

-- 
Andrew

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

#2083

On Jun 6, 11:08 pm, Andrew Reilly <areilly...@bigpond.net.au> wrote:

> I don't know: that seems exactly where little-endian would help, because
> when you are computing character at-a-time you almost certainly have
> different-length strings of digits, and we know that you want to add
> those by starting with the least-significant digit of each string.  With
> big-endian you have the extra step of first having to figure out where
> the least significant digit is.
>
> Presumably in the days where "introduction to programming" implied IBM
> 1401 or IBM 705 then it also implied fixed-width fields and implicit
> leading zeros, so perhaps it wasn't as complicated as I suggested.

The IBM 7070 was a decimal computer with a fixed-length word, but the
1401 and 705 indeed handled variable-length decimal numbers.

The IBM 1401 solved the problem you note quite simply: the most
significant digit of a number had a word mark... and the address of an
instruction operating on a number pointed to its least significant
digit. So the computer simply counted backwards to get successive
digits.

And addresses also pointed to the units position on the IBM 705,
although it didn't have word marks, and delimited numbers in a
different fashion.

John Savard

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

#2379

Quadibloc wrote:
>...
>Unless, of course, you are a native speaker of Hebrew or Arabic. In
>that case, it's little-endian computing that is natural.

No. Even in Hebrew numbers are written left-to-right.

Going off topic, this creates very interesting problems on how to
split (as in word processing,) lines that contain both right-to-left
and left-to-right (numbers and western languages) segments.
--
Roberto Waltman

[ Please reply to the group.
  Return address is invalid ]

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

#2380

On Tue, 05 Jul 2011 20:00:09 -0400, Roberto Waltman
<usenet@rwaltman.com> wrote, in part:

>Quadibloc wrote:
>>...
>>Unless, of course, you are a native speaker of Hebrew or Arabic. In
>>that case, it's little-endian computing that is natural.
>
>No. Even in Hebrew numbers are written left-to-right.

Which is precisely _why_ little-endian computing is natural in Hebrew
(and in Arabic, where, similarly, numbers are written from left to
right).

Because successive letters in a text document would be stored in
consecutive ascending locations in memory *regardless* of the direction
in which they are written on paper. So what makes little-endian notaion
natural is the _relationship_ between digit direction and text
direction.

John Savard
http://www.quadibloc.com/index.html

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

#2044

On Sun, 5 Jun 2011 11:00:58 -0700 (PDT), "Paul A. Clayton"
<paaronclayton@gmail.com> wrote:

>On Jun 5, 1:36 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
>[snip]
>> Because being big-endian was the *obvious* right way to design a
>> computer - write the numbers in the computer's memory the same way you
>> see them on a piece of paper! So that people can program in assembly
>> language without going insane.
>
>While on the subject of endian choice, when and why was endian
>nature of bits consistently made little-endian?

The "why", as I understand it, was that LE saves a cycle in address
calculation when the address is wider than the ALU.  I don't know if
that is true ... it seems to me that it would be more a function of
the data paths and would/could be the same cycle count either way ...
but that's the story I've heard. 

As to the "when" I have no idea.

>It seems to me that one would desire the endian nature of
>'bytes' to be the same as that of bits, but bits are (at least
>now) consistently little-endian while the byte-endian is
>more diverse.

Depends on the chip.  I've worked a lot with DSPs that were reversed
bit-wise from the memory you'd like to attach.  Never presented a
problem though - just swap the lines.

>(I generally favor big-endian representation because the high
>order bits are 'more significant'; but little-endian representation
>certainly better fits variable-length addition and could provide
>more frequent early out of equal comparison when the low order bits
>are more variable--which I suspect is a common case.  It also seems
>that string libraries could have benefited from endian awareness
>for sorting--at least before unicode.)

George

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

#2046

On Jun 5, 12:00 pm, "Paul A. Clayton" <paaronclay...@gmail.com> wrote:

> While on the subject of endian choice, when and why was endian
> nature of bits consistently made little-endian?

That, I think, is probably due to the microcomputer revolution. With
both 8-bit and 16-bit chips, it just seemed to make sense for the data
bus line and the address bus line that signified the values 1, 2, 4,
8, 16, and so on to have the same numbers regardless of the width of
the bus.

Remember that a typical 8-bit chip would have an 8-bit data bus and a
16-bit address bus.

John Savard

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

#2082

"Paul A. Clayton" <paaronclayton@gmail.com> writes:


> While on the subject of endian choice, when and why was endian
> nature of bits consistently made little-endian?

As other's have said, it wasn't a universal choice.  But it makes a lot
of sense to number the least significant bit 0 and so on (i.e.,
zero-based little endian), because bit number n then corresponds to 2^n.
That said, binary numbers are typically written in big-endian notation
like any other number.  This is reflected in the use of "shift left" to
mean a bitwise shift towards more significant numbers and conversely for
"shift right".

Since you can walk through memory in any order, in practice it makes
little difference how the bytes are laid out in memory.  Endianness
might matter a bit for serial communication if you want to start
computation before the full number is transferred, but I can't see many
applications where this is important -- communication time vastly
exceeds computation time anyway.

	Torben

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

#2086

"Torben Ægidius Mogensen"  wrote in message 
news:7z39jmrpoi.fsf@ask.diku.dk...

"Paul A. Clayton" <paaronclayton@gmail.com> writes:


> While on the subject of endian choice, when and why was endian
> nature of bits consistently made little-endian?

"

As other's have said, it wasn't a universal choice.  But it makes a lot
of sense to number the least significant bit 0 and so on (i.e.,
zero-based little endian), because bit number n then corresponds to 2^n.
That said, binary numbers are typically written in big-endian notation
like any other number.  This is reflected in the use of "shift left" to
mean a bitwise shift towards more significant numbers and conversely for
"shift right".

"

You are mixing two totally different concepts here which is a wrong thing to 
do.

There are two concepts at play:

1. General numbering of things, most people start counting at either zero or 
1 and proceed upwards,
Examples are, the alphabet,  A is usually considered zero and Z is 
considered 26.

Other example: 0 is a bad grade, 10 is a good grade.
Other example: 1 star is bad, 5 stars is great.

Higher numbers mean higher value.

The more memory one needs the higher the values. It's simply illogical to 
starts number at N back down to zero.

2. An exception is natural language/text where people write numbers as 
follows:

150

This means 1x100 + 1x50 + 1x0

Why people write like that is a subject by itself, but I wouldn't be too 
surprised if the answer is: lazyness and "false-easy-use" at basic schools.

People could also simply have used to opposite writing order:

051

Which would be more logical if we were used to reading from left to right 
assuming the highest number is on the right side.

So in a way our own language is a bit fucked.

We do read from left to right for normal sentences but for numbers suddenly 
we do it vice versa !? ;)


Finally shift left and shift right simply adepted to this fucked up natural 
language situation, it is after all an assembly menomic/shorthand for us 
humans to "easy" remember it, it (the direction) has nothing to do with what 
it actually does.

Therefore one could argue that these two descriptions were very badly chosen 
a better description would be:

"shift up" and "shift down"

However if we were to read vertically then it would be just as bad lol.

Perhaps "shift higher" and "shift lower" might be a bit better.

Bye,
  Skybuck.

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

#2085

"Paul A. Clayton"  wrote in message 
news:42477501-047c-4e2e-9697-a6275ad39af3@s14g2000vbi.googlegroups.com...

On Jun 5, 1:36 pm, Quadibloc <jsav...@ecn.ab.ca> wrote:
[snip]
> Because being big-endian was the *obvious* right way to design a
> computer - write the numbers in the computer's memory the same way you
> see them on a piece of paper! So that people can program in assembly
> language without going insane.

"
While on the subject of endian choice, when and why was endian
nature of bits consistently made little-endian?
"

I guess it was when they came to their senses and understood that big endian 
is bullshit and little endian is logical.

One starts numbering at the lowest value first.

0 to X and not vice versa.

Perhaps software programmers were involved in this decision and not so much 
hardware people ;)

Little endian probably also makes more sense for arithmetic.

7 mod 7 would wrap back to zero, which then gives a nice chance to start 
over from 0... would you really want the biggest number/value to be at zero 
?!? That would be weird.

Bye,
  Skybuck. 

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

#2042

On Sun, 5 Jun 2011 10:36:44 -0700 (PDT), Quadibloc <jsavard@ecn.ab.ca>
wrote:

<snip>
>The idea that no one really has to program in assembler... well, C
>wasn't invented yet.

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.

Louis

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

#2048

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

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

#2049

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?
They would have to make the exe file format secret and maybe ban
disassemblers or something. A policy that sounds ripe for hacking.

Eric

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

#2050

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.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#2060

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.

Eric

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

#2062

On 6/6/2011 10:34 AM, EricP 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.

That indeed used to be a hole, but it was fixed some time ago.  I don't 
know the details.  Perhaps someone else could chime in here.


> 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.

Do do you fault Intel/AMD for not selling the customer a microcode 
assembler, etc?  After all, the customer bought the chip.

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.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#2074

On 6/6/2011 10:49 AM, Stephen Fuld wrote:
> On 6/6/2011 10:34 AM, EricP 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>

>>>> 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.
>
> That indeed used to be a hole, but it was fixed some time ago. I don't
> know the details. Perhaps someone else could chime in here.
>
>
>> 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.
>
> Do do you fault Intel/AMD for not selling the customer a microcode
> assembler, etc? After all, the customer bought the chip.
>
> 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.

The problem with Burroughs' model is that you have to prove the compiler 
and/or assembler correct.

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

#2084

"Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> writes:
> 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.
>
> The problem with Burroughs' model is that you have to prove the
> compiler and/or assembler correct.

note that 801/risc started out w/o privilege levels and pl.8 would only
generate valid programs and only (cp.r) loader would load pl.8 valid
programs. 

the early presentations that the various hardware simplifications would
be compensated by more sophisticated software. one of the issues were
limited number of shared objects (shared segments were done by 16
registers, 32bit addressing with top four bits selecting one of the 16
segment registers. applications could use a large number of shared
objects by having inline code that changed segment register values (as
easily as changing general register values).

(801/risc) romp was joint res/opd project running cp.r for a
displaywriter followon. when that effort was canceled they looked around
for something else to use it for and settleed on the unix workstation
market. that applied moving to c-language & unix model and retrofitting
kernel/user privilege (although was stuck with the 16 segment register
design).

misc. old email mentioning 801/risc
http://www.garlic.com/~lynn/lhwemail.html#801

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

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

#2096

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.



-- 
  - Stephen Fuld
(e-mail address disguised to prevent spam)

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

#2147

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...

I do not know exactly what bugs in the Burroughs systems resulted in 
Gligor's expression of a policy requirement for user/kernel.  Rumors 
abound that they were quite serious.  Perhaps a freedom of information 
inquiry may one day find out what they were.

---

For a while while Java was young, and the idea of cell phones running a 
pure Java environment was current, the notion of a purely software 
enforced JVM bassed security arose again.  It seems to have disappeared.

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

#2150

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?

Eric

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

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

Back to top | Article view | comp.arch

csiph-web