8-bit bytes and byte-addressed machines

[Anton Ertl]

The IBM 360 is often credited with introducing or at least widely
popularising 8-bit bytes and byte addressing, and probably rightly so,
but I wonder how the IBM 360 influenced the early microprocessor
makers. Maybe, if Intel had decided to make a 7007 instead of the
8008, we would be using the AMD56 architecture now.

So was it an influence coming from the IBM 360 that made Intel (and
also Motorola and other Microprocessor makers) decide to go with 8-bit
bytes, was it technical reasons (like better compatibility with 4-bit
CPUs), or was it just an arbitrary decision (unlikely given that all
early microprocessors I know of (except the 4004) used 8-bit bytes).

Likewise, for 8-bit CPUs with larger address spaces byte addressing
was a pretty obvious choice, but maybe byte addressing was the cause
and 8-bit CPUs (rather than 16-bit) were the effect. One might argue
that die size constraints are the cause for 8-bit CPUs, but the b16
<http://bernd-paysan.de/b16.html> (and even more so the b16-small) is
smaller than an 8051, and by removing byte addressing it could be made
even smaller.

So, why did microprocessor makers decide on byte addressing and an
8-bit byte. Did they want compatibility with something influenced by
the IBM 360, or was it something else?

- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[Quadibloc]

On Sep 24, 3:44 am, an...@mips.complang.tuwien.ac.at (Anton Ertl)
wrote:

> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte.  Did they want compatibility with something influenced by
> the IBM 360, or was it something else?

I think that it is exactly how you first phrased it, and that
something influenced with the IBM 360 was the PDP-11.

The 6502 and the 8080 even tried to compare their architectures to the
PDP-11 in advertising. The later 16-bit 9900 was a lot like the PDP-11
in basic instruction set design, despite being big-endian.

John Savard

[Anonymous]

an...@mips.complang.tuwien.ac.at (Anton Ertl) wrote:

> The IBM 360 is often credited with introducing or at least widely
> popularising 8-bit bytes and byte addressing, and probably rightly so,
> but I wonder how the IBM 360 influenced the early microprocessor
> makers. Maybe, if Intel had decided to make a 7007 instead of the
> 8008, we would be using the AMD56 architecture now.

It would seem from Intel's other horrific blunders and foolish missteps over
the past decades they were and are relatively hostile to outside influences
and they seem to have gone out of their way several times to shoot themselves
in the foot. IBM has always had a 4K instruction segment relative to the
code base register. Intel's 64K segment was positively luxurious in
comparison but they had so few registers available they made it much harder
to use their system than it should have been. IBM made the transitions from
24 bit to 31 bit to 64 bit addressing painless and absolutely transparent.
You can link 24, 31, and 64 bit code in one executable and programs in any
mode or residency can call other programs in any mode and residency. 64 bit
code doesn't require any larger data footprint than 24 bit code except where
you need to store an actual 64 bit address, since there are intructions to load
addresses of various sizes cleanly from various length operands. The code
footprint is the same because IBM had plenty of room in their instruction
encodings. 64 bit registers are usable in 31 and 24 bit mode.

AMD and Intel flubbed the 32 to 64 bit changeover so badly they still
haven't fixed it and it will probably require changes to ELF and various OS
to do it correctly, which isn't going to happen overnight. Nobody seemed to
have a clue on this, and they should have seen it coming from the 16 bit to
32 bit changeover but they didn't.

Intel's instruction encoding is bizarre and complicated in the extreme. It's
amusing to see how numb Intel users have become to the fact, they don't even
consider it odd anymore. On Intel some intructions that are available in
16/32 bit mode (AAA comes to mind) don't work in 64 bit mode, you can't use
registers in the wrong mode, and you can't link an executable that contains
programs in different modes. I'm sure the Intel experts among you know even
more problems and inconsistencies. As far as I know IBM has none of these
problems. IBM is very careful with evolution. Object code from the 1960s
still runs on the latest hardware. At the same time, there is very little
apparent legacy burden on the instruction set, software, or OS.

Given IBM was there first in all cases, and did things seamlessly and
elegantly (and their tech pubs are freely available online) there really
isn't any excuse for Intel's consistent history of embarassing fuckups.

> So was it an influence coming from the IBM 360 that made Intel (and
> also Motorola and other Microprocessor makers) decide to go with 8-bit
> bytes, was it technical reasons (like better compatibility with 4-bit
> CPUs), or was it just an arbitrary decision (unlikely given that all
> early microprocessors I know of (except the 4004) used 8-bit bytes).

I think Motorola and other chipmakers probably did keep a close eye on IBM
although nobody seems to have adopted their hardware/software as a package
philosophy except perhaps to a much less extent Sun with Solaris/SPARC, and
that was also a very nice platform.

> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte. Did they want compatibility with something influenced by
> the IBM 360, or was it something else?

Unless there are people who worked at Intel in the 1970s participating in
this list, I think the best we can do is conjecture. Personally, I'm very
sick of Intel's shitty "engineering" and I'm glad to see other companies and
architectures make headway whenever they can.

[ChrisQ]

On 09/24/12 09:44, Anton Ertl wrote:
> The IBM 360 is often credited with introducing or at least widely
> popularising 8-bit bytes and byte addressing, and probably rightly so,
> but I wonder how the IBM 360 influenced the early microprocessor
> makers. Maybe, if Intel had decided to make a 7007 instead of the
> 8008, we would be using the AMD56 architecture now.
>
> So was it an influence coming from the IBM 360 that made Intel (and
> also Motorola and other Microprocessor makers) decide to go with 8-bit
> bytes, was it technical reasons (like better compatibility with 4-bit
> CPUs), or was it just an arbitrary decision (unlikely given that all
> early microprocessors I know of (except the 4004) used 8-bit bytes).
>
> Likewise, for 8-bit CPUs with larger address spaces byte addressing
> was a pretty obvious choice, but maybe byte addressing was the cause
> and 8-bit CPUs (rather than 16-bit) were the effect. One might argue
> that die size constraints are the cause for 8-bit CPUs, but the b16
> <http://bernd-paysan.de/b16.html> (and even more so the b16-small) is
> smaller than an 8051, and by removing byte addressing it could be made
> even smaller.
>
> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte. Did they want compatibility with something influenced by
> the IBM 360, or was it something else?
>
> - anton

8 bits is the smallest even number of bits that is capable of representing
a character in IBM"s ebcdic character set and it also fits in well with
the comms protocols of the time. In an age where memory was expensive, the
use of any more bits would have been wastefull.

When you consider that much of the work done in computing involves text
processing of some sort, it makes sense to have a text friendly machine
data format...

Regards,

Chris

[EricP]

Anton Ertl wrote:
>
> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte. Did they want compatibility with something influenced by
> the IBM 360, or was it something else?

I doubt that it was an homage to the 360 or for compatibility
as micros were originally intended as industrial controllers.

Selecting a power of 2 for the byte size has logic advantages.
It is simple matter that it is easier to build an 8 bit counter
than a 7 or 9 bit one. Serializing a 7 bit byte requires a 3 bit
counter but requires an extra AND gate and wastes 1 of the 8 states.
Multiplexing a 9 bit byte uses a 16:1 selector but
waste 7 of the 16 inputs.
8 is juuuuust right.

So it would have been a power of 2.
4 is too small, 16 too big. So 8 it is.

Eric

[EricP]

EricP wrote:
>
> It is simple matter that it is easier to build an 8 bit counter
> than a 7 or 9 bit one.

I mean an 8 state counter than a 7 or 9 state one.

Eric

[EricP]

Anton Ertl wrote:
>
> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte. Did they want compatibility with something influenced by
> the IBM 360, or was it something else?

I think the question is why did anyone, micro or mainframe,
use OTHER than 8 bit bytes?

The PDP-8 with 6 bit bytes and 12 bit words I can understand
because it used diode-transistor logic, probably 1 gate per
3 cm by 3 cm circuit board, so those 2 extra bits would
add a lot of cost.

But I don't understand tha rational for 9 bit bytes and 36 bit words.

Eric

[Quadibloc]

On Sep 24, 12:16 pm, EricP <ThatWouldBeTell...@thevillage.com> wrote:

> I think the question is why did anyone, micro or mainframe,
> use OTHER than 8 bit bytes?

Historically, before the IBM 360, almost all computers used an
uppercase-only character set, and stored characters 6 bits to a word.

So the CDC 6600 had a 60-bit word, the CDC 1604 had a 48-bit word, the
IBM 7090 and the PDP-6 had a 36-bit word, the SDS 940, the Datacraft
6024, and the DDP-116 had a 24-bit word, the PDP-1 and PDP-4 had an 18-
bit word, and the PDP-8 had a 12-bit word. Just as a small handful of
examples.

John Savard

[Robert Wessel]

36 bits was a good choice for scientific machines (IOW, ones intended
to do FP math as their main workload). 36 bits gives you a usefully
sized single precision float. 32 bits is too small (consider the pain
caused by the transition to 32 bit floats in S/360 - that was a huge
driver to using doubles instead).

Once you have 36 bit words, 6 bit characters made a lot of sense, as
lower cases letters were not considered essential, particularly in the
scientific world (and 64 characters pretty much covers what you need
if you don't need lowercase).

9 bit characters came from the need to support lower case letters, and
still fit in the 36 bit word.

Other machines did it differently. A number of early CDC machines
used 60 bit words, and either 6 or 10 bit characters depending on the
application.

[John Levine]

>The PDP-8 with 6 bit bytes and 12 bit words I can understand ...

The PDP-8 was word addressed. If you wanted to pack smaller things
into words, you had to do it by shifting and masking.

IBM explained their decision to use eight bit bytes in
the IBM Systems Journal in 1964:

Character size, 6 us 4/8. In character size, the funda- mental problem
is that decimal digits require 4 bits, the alphanumeric characters
require 6 bits. Three obvious alternatives were considered - 6 bits
for all, with 2 bits wasted on numeric data; 4 bits for digits, 8 for
alpha- numeric, with 2 bits wasted on alphanumeric; and 4 bits for
digits, 6 for alphanumeric, which would require adoption of a 12-bit
module as the minimum addressable element. The 7-bit character, which
incorporated a binary recoding of decimal digit pairs, was also
briefly examined.

The 4/6 approach was rejected because (a) was desired it to have the
versatility and power of manipulating character streams and addressing
individual characters, even in models where decimal arithmetic is not
used, (b) limiting the alphabetic character to 6 bits seemed
short-sighted, and (c) the engineering complexities of this approach
might well cost more than the wasted bits in the character.

The straight-6 approach, used in the IBM 702-7080 and 1401-7010
families, as well as in other manufacturers' systems, had the
advantages of familiar usage, existing 1/0 equipment, simple
specification field structure, and of commensurability with a 48-bit
floating-point word and a 24-bit instruction field.

The 4/8 approach, usedin the IBM 650-7074 family and elsewhere, had
greater coding efficiency, spare bits in the alphabetic set (allowing
the set to grow), and commensurability with a 32/64-bit floating-point
word and a 16-bit instruction field. Most important of these factors
was coding efficiency, which arises from the fact that the use of
numeric data in business records is more than twice as frequent as
alphanumeric. This efficiency implies, for a given hardware
investment, better use of core storage, faster tapes, and more
capacious disks.

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Del Cecchi]

The first micro processors used 4bits, as in the intel 4004 which was
descended from calculators. A logical extension is to put two digits in
an 8 bit byte.

[Tom Gardner]

EricP wrote:

> But I don't understand tha rational for 9 bit bytes and 36 bit words.

In that case you'll be baffled by the Elliott 803, a
successful minicomputer, that had 39 bit words.

See http://en.wikipedia.org/wiki/Elliott_803 for why.

Unrelated "why on earth did they do that?"...

The last coaxial transatlantic cable, TAT7, had an impedance
of 61.8 ohms. Why 61.8, when the common cable impedance was
50 or 75 ohs?

Simple: that turned out to be the only possible value:
- inner steel conductor had to be strong enough to support
the weight as the cable dropped to the ocean, so its
diameter was fixed
- outer diameter dictated by the need to fit the cable
in the cable-laying ship
- dielectric was polythene
and the impedance is determined by those three values.

[Tom Gardner]

Del Cecchi wrote:
> The first micro processors used 4bits, as in the intel 4004 which was descended from calculators. A logical extension is to put two digits in an 8 bit byte.

And there was at least one 1-bit micro, the Motorola 14500.

No, I'm not including bit-serial implementations of
processors as being "1-bit"

[Robert A Duff]

EricP <ThatWould...@thevillage.com> writes:

> Selecting a power of 2 for the byte size has logic advantages.

OK. But here's a different question:

There are lots of machines with non-power-of-2 byte size (where "byte"
is defined to mean "the addressable unit", i.e., "the thing an address
points at"). But all the machines I know have a word size that is a
power-of-2 times the byte size. That includes word-addressable
machines, where the word size is 2**0 (= 1) times the byte size.

Are there any exceptions to that?
Are any such in common use today?

I'm just a software guy, but I'm guessing the hardware wants to detect
[un]aligned loads and stores, and that's cheapest if you can just check
the low-order bits being zero. Hence, the word size must be a
power-of-2 times the byte size. True?

I know about the PDP-10, which has something called "bytes", but those
aren't "bytes" by the above definition -- it's a word-addressable machine
with 36-bit words (2**18 of them).

Another question: Why don't we have 1-bit bytes, with 64-bit words?
And load/store instructions that load/store aligned 1,2,4,8,16,32,64-bit
memory locations to/from 64-bit registers? With and without sign
extension? Seems like it would be hugely useful to index into a packed
array of Booleans without doing shifting and masking.

- Bob

[MitchAlsup]

On Monday, September 24, 2012 5:37:20 PM UTC-5, Robert A Duff wrote:
> There are lots of machines with non-power-of-2 byte size (where "byte"
> is defined to mean "the addressable unit", i.e., "the thing an address
> points at").

Name one that ships more than 1M/yr.

> I'm just a software guy, but I'm guessing the hardware wants to detect
> [un]aligned loads and stores, and that's cheapest if you can just check
> the low-order bits being zero. Hence, the word size must be a
> power-of-2 times the byte size. True?

Only assuming you have bytes defined. Many of the 60-bit machines did not.

But in the modern sense, yes, it is easy to check for alignment issues by
looking at lower order bits of the address. On the other hand, word addressed
machines do all of this in the registers with instructions.

> Another question: Why don't we have 1-bit bytes, with 64-bit words?

It is a definitional issue. Bytes have more than 1 bits in them.

> And load/store instructions that load/store aligned 1,2,4,8,16,32,64-bit
> memory locations to/from 64-bit registers? With and without sign
> extension? Seems like it would be hugely useful to index into a packed
> array of Booleans without doing shifting and masking.

Useful, yes; burns up opcode space? Badly. But basically, there is little
"perceived" use of 1,2,4 bit items. A bit of chicken and egg problem as
there are no instructions to load/store 1,2,4 bit items.

Why is 8 more special than 1,2,4? because ASCII characters fit in 8-bit
containers and the full UASCII setfits in 16-bit containers.

Applications need the ability to run down a string of characters and make
sense of it, often and repeatedly--as this is the most normal way of dealing
with the people who pay for things (i.e. humans). Thus, 8-bits is de regeur.

Mitch

[Michael S]

On Sep 25, 1:07 am, MitchAlsup <MitchAl...@aol.com> wrote:
> On Monday, September 24, 2012 5:37:20 PM UTC-5, Robert A Duff wrote:
> > There are lots of machines with non-power-of-2 byte size (where "byte"
> > is defined to mean "the addressable unit", i.e., "the thing an address
> > points at").
>
> Name one that ships more than 1M/yr.

By now, I don't know. But in relatively recent past (as slightly more
than decade ago) Motorola 56K family of 24-bit DSPs was easily above
1M/yr

Analog Device's SHARC (48b code words, 40b data words) probably didn't
reach 1M/yr even at its peak, but it was pretty expensive chip (not
now, back in late 90s to early 00s, what's left from that family is
relatively cheap), so at less than 1M/year it made more $$$ then many
of those that were above 1M.

[Michael S]

On Sep 25, 12:37 am, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:

>
> Another question:  Why don't we have 1-bit bytes, with 64-bit words?

Do you mean, something like that?
http://en.wikipedia.org/wiki/TMS34010

[Michael S]

On Sep 24, 10:49 pm, John Levine <jo...@iecc.com> wrote:
> >The PDP-8 with 6 bit bytes and 12 bit words I can understand ...
>
> The PDP-8 was word addressed.  If you wanted to pack smaller things
> into words, you had to do it by shifting and masking.
>
> IBM explained their decision to use eight bit bytes in
> the IBM Systems Journal in 1964:
>
> Character size, 6 us 4/8. In character size, the funda- mental problem
> is that decimal digits require 4 bits, the alphanumeric characters
> require 6 bits. Three obvious alternatives were considered - 6 bits
> for all, with 2 bits wasted on numeric data; 4 bits for digits, 8 for
> alpha- numeric, with 2 bits wasted on alphanumeric; and 4 bits for
> digits, 6 for alphanumeric, which would require adoption of a 12-bit
> module as the minimum addressable element. The 7-bit character, which
> incorporated a binary recoding of decimal digit pairs, was also
> briefly examined.
>

I wonder why 7-bit characters were rejected?
7-bit looks better than 8-bit both from decimal digit density
perspective and provides rather useful (at least for American market)
alphanumerics.
The only downsize I can think about is slightly more complex logic
required for text<->decimal conversions. But still not too complex.

[Stephen Sprunk]

It's all about the BCD.

An 8-bit byte allows manipulating 4-bit BCD digits separately, whereas a
7-bit byte requires encoding pairs of BCD digits--and that means more
logic is required to manipulate them, which apparently was enough to
outweigh the small gain in storage efficiency.

BCD was a big, big deal back then--and probably still is, to many of
IBM's customers. Prior to AMD64, even x86 had BCD opcodes that traced
their roots back to the 4004.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Robert Wessel]

On Mon, 24 Sep 2012 18:37:19 -0400, Robert A Duff
<bob...@shell01.TheWorld.com> wrote:

>EricP <ThatWould...@thevillage.com> writes:
>
>> Selecting a power of 2 for the byte size has logic advantages.
>
>OK. But here's a different question:
>
>There are lots of machines with non-power-of-2 byte size (where "byte"
>is defined to mean "the addressable unit", i.e., "the thing an address
>points at"). But all the machines I know have a word size that is a
>power-of-2 times the byte size. That includes word-addressable
>machines, where the word size is 2**0 (= 1) times the byte size.
>
>Are there any exceptions to that?

Sure, most of the 36 bit and 60 bit machines. Before many of the 36
bit machines went to 9-bit characters, they often held six 6 bit
characters in a machine word. As I mentioned in my other post, the
CDC6600 and successors used 60 bit words, and either 6 or 10 bit
characters.

How those were physically addressed was all over the map - in that era
the machines were usually word addressed (IOW, the first word was
address zero, the second address 1, etc.), and software had to hack up
some way to deal with sub-word (character) addresses.

Some machines had special hardware/instructions for handling
"character" pointers.

One nice thing about approximately all modern word oriented machines
is that the addressing of sequential words is the number of bytes in a
word apart.

>Are any such in common use today?

How do you want to count machines with separate data and code spaces?
A number of microcontrollers with 8 b it data memory have rather odd
sized instruction words (although those are not really addressable as
ordinary data).

>I'm just a software guy, but I'm guessing the hardware wants to detect
>[un]aligned loads and stores, and that's cheapest if you can just check
>the low-order bits being zero. Hence, the word size must be a
>power-of-2 times the byte size. True?
>
>I know about the PDP-10, which has something called "bytes", but those
>aren't "bytes" by the above definition -- it's a word-addressable machine
>with 36-bit words (2**18 of them).
>
>Another question: Why don't we have 1-bit bytes, with 64-bit words?
>And load/store instructions that load/store aligned 1,2,4,8,16,32,64-bit
>memory locations to/from 64-bit registers? With and without sign
>extension? Seems like it would be hugely useful to index into a packed
>array of Booleans without doing shifting and masking.

There have been bit addressed machines.

[Terje Mathisen]

Robert A Duff wrote:
> I'm just a software guy, but I'm guessing the hardware wants to detect
> [un]aligned loads and stores, and that's cheapest if you can just check
> the low-order bits being zero. Hence, the word size must be a
> power-of-2 times the byte size. True?

No, mainly you want to be able to go between bytes and words with simple
shifts, i.e. no mul/div by 3, 5, 6 or 17.

The latter have of course been tried, in the form of 17-banked memory,
and it does have some benefits, but not enough to be emulated by many
subsequent machines.

>
> I know about the PDP-10, which has something called "bytes", but those
> aren't "bytes" by the above definition -- it's a word-addressable machine
> with 36-bit words (2**18 of them).
>
> Another question: Why don't we have 1-bit bytes, with 64-bit words?
> And load/store instructions that load/store aligned 1,2,4,8,16,32,64-bit
> memory locations to/from 64-bit registers? With and without sign
> extension? Seems like it would be hugely useful to index into a packed
> array of Booleans without doing shifting and masking.

Most machines have instructions which allow fast access to single bits
or consecutive groups of bits within a single (aligned) register-sized word.

Since the actual memory transfer has to happen in cache-line sized
blocks to/from RAM, and (as an absolute minimum) in byte-sized chunks
between cache and registers, shifts and masks are fast enough when you
need to work with bits.

I suspect that currently a big majority (90%?) of all bit-level memory
access occur in the form of compression/decompression, where you mostly
need to extract the next N (unaligned) bits from a data stream.

The canonical solution is to cache the current word (or two) in a
register, then shift it down as bits are being used, and refill when you
have room for another word. This is fast enough to keep up with actual
memory speeds at least.

If you need something even more funky, you would probably like a generic
masked extract/insert, where you input a word and a mask and get back a
packed set of bits consisting of those bit positions that were set in
the mask. This is a relatively expensive operation though, since it
requires variable shifts for every input bit, but maybe Mitch has fast
way to do it?

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

[EricP]

Anton Ertl wrote:
>
> So, why did microprocessor makers decide on byte addressing and an
> 8-bit byte. Did they want compatibility with something influenced by
> the IBM 360, or was it something else?

The 8008 had 8 bit data registers and a 14 bit address.
It was developed by Intel under contract to CTC.
The instruction set architecture of the 8008 was
designed by Victor Poor of CTC for the Datapoint 2200.
Intel couldn't meet CTC's deadline so CTC decided to use
TTL for the 2200 cpu and gave Intel the rights to the 8008.

http://en.wikipedia.org/wiki/Intel_8008
http://en.wikipedia.org/wiki/Datapoint_2200
http://en.wikipedia.org/wiki/Victor_Poor

8 bits was probably chosen because it could hold 2 BCD digits
or 1 ascii char (due to the 4004 roots as a scientific calculator).

Once 8 bits was established, support chips like PROMs and SRAM
would be developed in 8 and 4 bit wide variants as that
minimized the number of memory chips an embedded system needs.

With the prom chips established as 8 bits wide,
all later chips (8080, 6800, 6502) have to follow suit.

Eric

[Anton Ertl]

an...@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>So, why did microprocessor makers decide on byte addressing and an
>8-bit byte. Did they want compatibility with something influenced by
>the IBM 360, or was it something else?

Researching a little more (in Wikipedia:-), it seems that the Intel
8008 was designed for the Datapoint 2200 programmable terminal, which
probably specified 8-bit bytes for compatibility with the IBM 360.

The 6800 had a decimal adjust instruction, so BCD may have been one of
the factors that led the an 8-bit byte there.

Wikipedia also claims influence by the PDP-11 on the 6800, and that
the 16-bit width of the PDP-11 was influence by the Nova. Now the
Nova was apparently a word-addressed machine (judging from the
assembly-language example on the Wikipedia page), and its use of a
multiple of 4 was probably due to the 74181 chip (not sure why the
74181 was 4 bits wide, maybe BCD, or maybe it was just what fit on a
chip).

[Anton Ertl]

ChrisQ <blac...@devnull.com> writes:
>8 bits is the smallest even number of bits that is capable of representing
>a character in IBM"s ebcdic character set

EBCDIC would have been an influence by the IBM 360, but most stuff
built with microprocessors (including IBM's PC) used ASCII, so EBCDIC
probably was not an important consideration. ASCII was 7-bit, so if
text was the main application, 7-bit bytes would have been fine.
Except of course when doing a programmable terminal like the Datapoint
2200 (for which the 8008 was designed) that might also want to talk to
IBM computers.

[Paul A. Clayton]

On Monday, September 24, 2012 7:07:06 PM UTC-4, MitchAlsup wrote:
> On Monday, September 24, 2012 5:37:20 PM UTC-5, Robert A Duff wrote:

[snip]

>> And load/store instructions that load/store aligned 1,2,4,8,16,32,64-bit
>> memory locations to/from 64-bit registers? With and without sign
>> extension? Seems like it would be hugely useful to index into a packed
>> array of Booleans without doing shifting and masking.
>
> Useful, yes; burns up opcode space? Badly. But basically, there is little
> "perceived" use of 1,2,4 bit items. A bit of chicken and egg problem as
> there are no instructions to load/store 1,2,4 bit items.

Spatial locality of boolean fields (so a register acts somewhat
usefully as a cache block) and lack of multithreaded use
without locks (so linked load/store conditional overhead is
not needed to store a bit) probably reduces the benefit of
bit-granular loads and stores. In addition, many boolean
values are probably used in ways that bitwise logical
operations with immediates are sufficient (I suspect even more
so if the ISA has branch on bit test instructions).

2-bit and 4-bit values are probably less frequently used
than boolean values. Lack of language support might be
more of a hindrance than lack of hardware support in those
cases. Outside of embedded systems, I would not be
surprised if non-character bytes are frequently used, so
the storage wasting of promoting 2-bit and 4-bit values
to 8-bit values might not be noticeably large.

Also, in the days when parity-based error detection was
enough, 8-bit bytes can avoid hardware read-modify-write
while only adding just over 9% overhead (relative to
32-bit word parity protection). (The Alpha designers
considered the RMW overhead in the presence of ECC
sufficient reason not to support 8-bit and 16-bit
accesses, though that decision might have been a mistake.)

It might be worth noting that some processors for
embedded systems support bit band regions where byte
addressing becomes bit addressing. I think this is
intended for I/O, so error detection in caches is not
an issue and speed of access is less important.

Supporting only register indirect addressing for small
accesses would not seem to eat that much encoding
space (especially in a traditional RISC with 32-bit
instructions--9 of 65536 two-register encodings within
a single major opcode would be used). Providing an
additional set of instructions using a small immediate
offset and using a byte-granular address in a register
might not be that much of an additional burden, but it
is not clear that it would provide much additional
benefit either. (Losing three bits of the address
space would seem to be inconvenient, especially for
software in a 32-bit system. Providing an addressing
mode using a register pair might be interesting, but
providing such just for bit granular addressing seems
excessive.)

[Noob]

MitchAlsup wrote:

> Thus, 8-bits is de regeur.

ITYM "de rigueur" ;-)

https://en.wiktionary.org/wiki/de_rigueur

[Paul A. Clayton]

On Tuesday, September 25, 2012 2:15:03 AM UTC-4, Terje Mathisen wrote:
[snip]

> If you need something even more funky, you would probably like a generic
> masked extract/insert, where you input a word and a mask and get back a
> packed set of bits consisting of those bit positions that were set in
> the mask. This is a relatively expensive operation though, since it
> requires variable shifts for every input bit, but maybe Mitch has fast
> way to do it?

That sounds similar to centrifuge (sheep-and-goats) except that
the mask is used to determine which are sheep. Andy Glew's
CompArch wiki has an article:
http://semipublic.comp-arch.net/wiki/Compress_bits_under_mask

Since Intel's Haswell provides PLEX, the implementation cost
might not be considered excessive.

[Paul A. Clayton]

On Tuesday, September 25, 2012 8:57:53 AM UTC-4, Paul A. Clayton wrote:
[snip]

> Since Intel's Haswell provides PLEX, the implementation cost
> might not be considered excessive.

Sorry, PEXT (Parallel bits EXTract)!

[MitchAlsup]

On Tuesday, September 25, 2012 1:15:03 AM UTC-5, Terje Mathisen wrote:
> If you need something even more funky, you would probably like a generic
> masked extract/insert, where you input a word and a mask and get back a
> packed set of bits consisting of those bit positions that were set in
> the mask. This is a relatively expensive operation though, since it
> requires variable shifts for every input bit, but maybe Mitch has fast
> way to do it?

If you have access to BitMatrixMultiply it falls out rather easily.

Otherwise, I am generally a fan of bit manipulation instructions
{Clear, Set, ExtractUnsigned, ExtractSigned, Make, and Insert.}
So you can do the field accesses one at a time single instruction
per datum.

Mitch

[Chris Gray]

Robert Wessel <robert...@yahoo.com> writes:

> Sure, most of the 36 bit and 60 bit machines. Before many of the 36
> bit machines went to 9-bit characters, they often held six 6 bit
> characters in a machine word. As I mentioned in my other post, the
> CDC6600 and successors used 60 bit words, and either 6 or 10 bit
> characters.

For the youngsters, why did file names on old systems like CP/M and early
DOS only allow 3 characters after the '.'?

I believe it goes back to the early DEC machines with 16 bit words.
To encode early file names, you only needed to allow upper case letters,
digits, underscores, and maybe one or two other characters.
26 + 10 + 4 = 40. 40 * 40 * 40 = 64000, which fits in 16 bits. The
encoding (3 characters per word) was called "Rad-50", since 40 is
written "50" in octal (which DEC liked).

I encountered Rad-50 when writing code to allow me to run the DEC
binary for "Adventure" under Unix on a PDP-11. Luckily, the DEC OS
used TRAP for system calls, which you could trap under Unix. Fun!

--
Chris Gray

[Jim Haynes]

On 2012-09-24, MitchAlsup <Mitch...@aol.com> wrote:
> On Monday, September 24, 2012 5:37:20 PM UTC-5, Robert A Duff wrote:
>
>> Another question: Why don't we have 1-bit bytes, with 64-bit words?
>
> It is a definitional issue. Bytes have more than 1 bits in them.

The IBM 7030 (STRETCH) was addressable to the bit level. I guess when they
designed the 360 they decided that being able to address to such a fine
grain required more address bits than was worthwhile. To some degree this
reflects the decreasing cost of memory. If all you had was 2048 words of
memory you'd be at pains to pack things as tightly into a word as possible.

>
> Why is 8 more special than 1,2,4? because ASCII characters fit in 8-bit
> containers and the full UASCII setfits in 16-bit containers.
>
> Applications need the ability to run down a string of characters and make
> sense of it, often and repeatedly--as this is the most normal way of dealing
> with the people who pay for things (i.e. humans). Thus, 8-bits is de regeur.
>
> Mitch

Also, again going back to the IBM 360 and expensive memory, you could pack
two decimal digits into an 8-bit byte.

By the time of the 360 people were begining to realize that a 6-bit
character set was insufficient. ASCII was officially 7 bits, and IBMs
competing EBCDIC used all 8 bits.


--
jhhaynes at earthlink dot net

[Anne & Lynn Wheeler]

Jim Haynes <jha...@alumni.uark.edu> writes:
> By the time of the 360 people were begining to realize that a 6-bit
> character set was insufficient. ASCII was officially 7 bits, and IBMs
> competing EBCDIC used all 8 bits.

minior caveat regarding ascii/ebcdic ... claims Learson made biggest
computer goof ever:
http://www.bobbemer.com/P-BIT.HTM

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

[Thomas Womack]

In article <6798acb6-1b67-44d0...@googlegroups.com>,

MitchAlsup <Mitch...@aol.com> wrote:
>On Tuesday, September 25, 2012 1:15:03 AM UTC-5, Terje Mathisen wrote:
>> If you need something even more funky, you would probably like a generic
>> masked extract/insert, where you input a word and a mask and get back a
>> packed set of bits consisting of those bit positions that were set in
>> the mask. This is a relatively expensive operation though, since it
>> requires variable shifts for every input bit, but maybe Mitch has fast
>> way to do it?

But, except in the MMIX case where BitMatrixMultiply applies the
matrix bytewise, BMM is a hopeless case on multi-tasking machines
because you need such a lot of special storage for the matrix ... even
on Cray I remember having to be careful because system calls broke the
matrix.

(I suppose current Intel hardware is close to having first-class
256-bit objects and so could work 16-bit-wordwise ...)

Tom

[Tim McCaffrey]

In article <uju7j9-...@ntp-sure.tmsw.no>, "terje.mathisenattmsw.no"
says...

>If you need something even more funky, you would probably like a generic
>masked extract/insert, where you input a word and a mask and get back a
>packed set of bits consisting of those bit positions that were set in
>the mask. This is a relatively expensive operation though, since it
>requires variable shifts for every input bit, but maybe Mitch has fast
>way to do it?
>

Haswell is supposed to have these instructions (at least the last time I
looked, which was awhile ago...)

- Tim

[Joe keane]

In article <2012Sep2...@mips.complang.tuwien.ac.at>,
Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>Maybe, if Intel had decided to make a 7007 instead of the 8008, we
>would be using the AMD56 architecture now.

So... microprocessors have power-of-two bytes because microprocessors
never had not-power-of-two bytes.

[Joe Pfeiffer]

It would be better to say it's because the advantages of power-of-two
bytes were figured out before there were microprocessors.

[John Levine]

>For the youngsters, why did file names on old systems like CP/M and early
>DOS only allow 3 characters after the '.'?
>
>I believe it goes back to the early DEC machines with 16 bit words.

Early DEC machines had 18 (PDP-1, -4, -7) or 36 (PDP-6) bit words.
Three six-bit characters fit nicely in 18 bits.

Nonetheless, some PDP-10 software used RAD50 to fit a six character name
into 32 bits so they had four bits for flags.

R's,
John
--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Joe keane]

In article <66581c48-59be-4454...@kr6g2000pbb.googlegroups.com>,
Quadibloc <jsa...@ecn.ab.ca> wrote:
>I think that it is exactly how you first phrased it, and that
>something influenced with the IBM 360 was the PDP-11.

IBM 360 instruction size: 16 bits, 32 bits, 48 bits
PDP-11 instruction size: 16 bits, 32 bits, 48 bits

everyone screwed it up from there

[Robert Wessel]

On Wed, 26 Sep 2012 01:59:14 +0000 (UTC), j...@panix.com (Joe keane)
wrote:

Basically true, with the usual caveat that there are exceptions. The
IM6100, for example, is essentially a microprocessor implementation of
the (12 bit) PDP-8.

[Quadibloc]

On Sep 24, 1:27 pm, Robert Wessel <robertwess...@yahoo.com> wrote:

> 36 bits was a good choice for scientific machines (IOW, ones intended
> to do FP math as their main workload).  36 bits gives you a usefully
> sized single precision float.  32 bits is too small (consider the pain
> caused by the transition to 32 bit floats in S/360 - that was a huge
> driver to using doubles instead).

So I'm not the only one...

http://www.quadibloc.com/arch/perint.htm

John Savard

[ken...@cix.compulink.co.uk]

In article <87d31ag...@GraySage.com>, c...@GraySage.com (Chris Gray)
wrote:

> For the youngsters, why did file names on old systems like CP/M and
> early DOS only allow 3 characters after the '.'?

I do not know about CPM but QDOS was written as "CPM" for the 8086.

Ken Young

[Noob]

Tim McCaffrey wrote:

> Terje wrote:
>
>> If you need something even more funky, you would probably like a generic
>> masked extract/insert, where you input a word and a mask and get back a
>> packed set of bits consisting of those bit positions that were set in
>> the mask. This is a relatively expensive operation though, since it
>> requires variable shifts for every input bit, but maybe Mitch has fast
>> way to do it?
>
> Haswell is supposed to have these instructions (at least the last time I
> looked, which was awhile ago...)

This might be of interest:
http://software.intel.com/en-us/blogs/2011/06/13/haswell-new-instruction-descriptions-now-available/

[Terje Mathisen]

According to that document, Haswell does not have the generic masked bit
extract/compress, but otoh it does have a few new scalar instructions
that I didn't realize were available:

ANDN And Not
BLSR, BLSMSK, BLSI Lowest set bit operations
LZCNT, TXCNT Leading/trailing zero count
BZHI Zero high bits

The new *X operations that explicitly ignores all flags are useful:
SARX, SHLX, SHRX, RORX, MULX

particularly together with the latest pair of Add With Carry/Add With
Overflow:

These are obviously designed to be used in parallel, so that you can do
carry propagation on two arrays simultaneously, one using the Carry flag
as in ADC, and the other one using the Overflow flag as a spare carry flag!

Terje
PS. One of the comments to the linked article also notes that BEXSTR,
PDEP, PEXT seems to be missing. Is this a documentation bug?

[John Levine]

>36 bits was a good choice for scientific machines (IOW, ones intended
>to do FP math as their main workload). 36 bits gives you a usefully
>sized single precision float. 32 bits is too small (consider the pain
>caused by the transition to 32 bit floats in S/360 - that was a huge
>driver to using doubles instead).

The 360 didn't just have shorter floats, but several design botches
lost three bits of precision in every operation. It's hard to tell
how much of the float code would have been OK with a competent 32 bit
float format.

[Tim McCaffrey]

In article <4ambj9-...@ntp-sure.tmsw.no>, "terje.mathisenattmsw.no"
says...

The document still has PDEP & PEXT (& BEXTR), plus lots of other stuff the
article doesn't mention. Probably the author didn't think they were
important. :(

- Tim

[BGB]

possibly...


but, it did mention half-floats, which probably many people may find
useful (less need to do conversions to/from half-floats in software).

although only packed versions are available, whereas something more like
'cvtsh2ss' or 'cvtss2sh' could have been useful (otherwise, it would
probably mostly just be useful for things like repacking arrays or
similar, rather than getting/setting individual half-float variables).

for example:
mov ax, [ecx+44] ;say, ecx is a struct
cvtsh2ss xmm0, ax
...
cvtss2ss ax, xmm0
mov [ecx+46], ax

this (probably) leaves this case still better served by a software
implementation.


or such...

[MitchAlsup]

On Wednesday, September 26, 2012 11:37:01 AM UTC-5, John Levine wrote:
> The 360 didn't just have shorter floats, but several design botches lost
> three bits of precision in every operation. It's hard to tell how much
> of the float code would have been OK with a competent 32 bit float format.

The original issue 360 did not even have a guard digit (4-bits) in use
in the FP calculations. This lead to a lot of lost precision. The error
was recognized very fast (months) and a retrofit was installed in the
machines in the field.

Hexidecimal exponents allowed 24-bits of fraction, but truncation (rather
than rounding) and hex-normalization gave 20.5 bits of actual precision.
IEEE754 single precision is about 1 more decimal digit better than IBM single.

When viewed in the light of the gastly CDC floating point arithmetic,
these issues don't seem as bad as they could have been (that is after IBM
fixed the guard digit thingie.)

Mitch

Mitch

[John Levine]

>> The 360 didn't just have shorter floats, but several design botches lost
>> three bits of precision in every operation. It's hard to tell how much
>> of the float code would have been OK with a competent 32 bit float format.
>
>The original issue 360 did not even have a guard digit (4-bits) in use
>in the FP calculations. This lead to a lot of lost precision. The error
>was recognized very fast (months) and a retrofit was installed in the
>machines in the field.

Right, that's the best they could do without changing the format.

>Hexidecimal exponents allowed 24-bits of fraction, but truncation (rather
>than rounding) and hex-normalization gave 20.5 bits of actual precision.
>IEEE754 single precision is about 1 more decimal digit better than IBM single.

They lost a bit to truncation, perhaps a bit and a half to hex normalization,
and another bit due to no hidden bit. Sounds about right.

>When viewed in the light of the gastly CDC floating point arithmetic,
>these issues don't seem as bad as they could have been (that is after IBM
>fixed the guard digit thingie.)

Still was worse than binary floats on 709x and contemporary 36 bit machines
like the PDP-6 and GE 635.

[Andy (Super) Glew]

MicroUnity claims to have solved this problem with their wide operand cache.

http://semipublic.comp-arch.net/wiki/Wide_operand_cache

Anecdote: I was discussing exactly this problem with Alex Klaiber,
trying to choose between TLB semantics or not, the morning that
MicroUnity presented it in the afternoon to us.




Anyway, the basic idea: some instructions want wide operands.
E.g. 64x64=512b for a BMM 64x64.

Now, 512b is not really all that large any more. LRB (and MIC?)
registers were that wide.

But imagine that you want a 4KB operand. A nice lookup table.


Anyway, you treat this as a memory operand. Put the address in a
register. But instead of loading every instruction, cache it. Only load
when the address is valid but the data is not.

Invalid the data on context switches. But preserve the address.

Heck, you might not define how many such wide operand cache entries you
have. So you might implement 4, and thrash with reloads when you need 5.

[Joe keane]

In article <1bmx0dx...@pfeifferfamily.net>,

Joe Pfeiffer <pfei...@cs.nmsu.edu> wrote:
>It would be better to say it's because the advantages of power-of-two
>bytes were figured out before there were microprocessors.

You're being generous.

Cray used 64 bits, but they still had word addressing. You can
implement 8-bit bytes, or 6-bit bytes or 10-bit bytes. <insert random
digression about VAX> Their 'solution' is to make 'char' 64 bits, so
you get one of the least efficient methods of storing text ever.

What really happened is that the 8008 and successors simply plowed
those-all guys into the ground.

[Terje Mathisen]

"Attack of the Killer Micros"

It would at least be safe to say that the IT world have simplified
itself a bit in this regard:

Memory is addressable in 8-bit byte increments.

Integers are stored as twos-complement, and come in power-of-two sizes.

FP is (more or less) IEEE 32 and 64-bit.

OTOH we have gotten gpgpu as well as lots of multicore programming models.

C still doesn't know how to work (portably) in such an environment.

We also have lots of different Virtual Machines, from the classic IBM
model to Java VM.

Terje

[MitchAlsup]

On Wednesday, September 26, 2012 10:49:29 PM UTC-5, Andy (Super) Glew wrote:
> Anyway, the basic idea: some instructions want wide operands.
> E.g. 64x64=512b for a BMM 64x64.

BTW 64*64 is 4096 bits or 8 modern cache lines.

Note, BMM is the ultimate bit manipulation instruction and is
inherently vector-op-scalar->scalar in nature.

It is my opinion that when you get to the point you want to support
things like BMM-64 you really want vector registers 64 entries deep
per vector, the alternative is to figure out how to stream 8 cache
lines through a vector BMM unit at 1 operand-64 per cycle.

Mitch

[Quadibloc]

On Sep 27, 8:23 am, j...@panix.com (Joe keane) wrote:

> Cray used 64 bits, but they still had word addressing.  You can
> implement 8-bit bytes, or 6-bit bytes or 10-bit bytes.  <insert random
> digression about VAX>  Their 'solution' is to make 'char' 64 bits, so
> you get one of the least efficient methods of storing text ever.

It made a perverse sort of sense. A Cray was built to do one thing
well, work with floating-point numbers - and adding hardware to do
other stuff better would have been wasted. Time on Crays wasn't spent
processing text to more than the most minimal extent one could get
away with.

> What really happened is that the 8008 and successors simply plowed
> those-all guys into the ground.

Microprocessors did indeed eventually plow everything else into the
ground. Considering that a Pentium is comparable to an IBM 360/195 in
basic architecture - but faster - it's hardly surprising.

In between the 8008 and, say, the 486 DX, there was no reasonable way
to implement a "big computer" - so the 8087 was something of a
godsend.

John Savard

[Ivan Godard]

And what prevents that?

Ivan

[MitchAlsup]

On Thursday, September 27, 2012 7:27:32 PM UTC-5, Ivan Godard wrote:
> And what prevents that?

Nothing,

But perhaps the lack of foresite of the architects implementing BMMs.

Mitch

[MitchAlsup]

On Thursday, September 27, 2012 6:17:09 PM UTC-5, Quadibloc wrote:
> It made a perverse sort of sense. A Cray was built to do one thing
> well, work with floating-point numbers - and adding hardware to do
> other stuff better would have been wasted. Time on Crays wasn't spent
> processing text to more than the most minimal extent one could get
> away with.

The symbol table lookup was vectorized in the CRAY 1 assembler and FORTRAN
compiler! If you understood what the CRAY1 was good at (memory and register
bandwidth) you could vectorize things that would not originally appear to
be vectorizable. Lots of string handling, and bit pattern matching stuff
(having nothing to do with FP codes).

Mitch

[Al Grant]

On Sep 28, 5:15 pm, MitchAlsup <MitchAl...@aol.com> wrote:
> The symbol table lookup was vectorized in the CRAY 1 assembler and FORTRAN
> compiler!

At a Cray site I used to work at, we found when switching
from COS (Cray's custom OS) to Unicos (Cray Unix), the
"cp" command was slower at copying a file than the COS
optimizing Fortran compiler was at compiling it.

[Przemek Klosowski]

On Wed, 26 Sep 2012 03:44:04 +0000, John Levine wrote:
> Nonetheless, some PDP-10 software used RAD50 to fit a six character name
> into 32 bits so they had four bits for flags.

Not just PDP-10---DEC system software for PDP-11 (which of course was the
essential 16-bit architecture that gave rise to Unix, C, VAX, CISC, and
all the other good things :) also used RAD50 to squeeze more
alphanumerical data. RAD50 allowed only upper case letters, numbers and a
bunch of punctuation and special characters.

[Brian Drummond]

Heh. I first came across RAD50 when a colleague gave me a report he
needed printed out urgently. I got landed with it because my then home
computer was the only one anyone knew, with both a printer and an 8"
floppy disk drive.

The report itself was, fortunately, in ASCII, but the filesystem was (a)
completely unknown to me (certainly not CP/M!), (b) packed 3 characters
into 2 bytes and (c) completely undocumented in my bookshelves. (No
internet access either). Turned out his home computer was a PDP-11.
(I don't know why he wasn't using the VAX 11/750 in his living room,
maybe it needed 3-phase power)

By about 3am I had a very crude directory reader in Z80 asm, so I could
find out which sectors belonged to the report, and transfer them to a CP/M
floppy whence I could actually print them...

- Brian

[Stephen Sprunk]

On 24-Sep-12 08:48, Anonymous wrote:
> It would seem from Intel's other horrific blunders and foolish
> missteps over the past decades they were and are relatively hostile
> to outside influences and they seem to have gone out of their way
> several times to shoot themselves in the foot.

Pretty much _every_ ISA that Intel has ever deliberately designed has
been a miserable failure. Their successes have been either accidents or
a result of copying someone else.

> AMD and Intel flubbed the 32 to 64 bit changeover so badly they
> still haven't fixed it and it will probably require changes to ELF
> and various OS to do it correctly, which isn't going to happen
> overnight. Nobody seemed to have a clue on this, and they should have
> seen it coming from the 16 bit to 32 bit changeover but they didn't.

It's far too late to change x86-64 now; that mistake was pretty much set
in stone a decade or so ago.

> Intel's instruction encoding is bizarre and complicated in the
> extreme.

Well, the original ISA made a reasonable amount of sense back when it
was designed, but there really wasn't any way to extend it in a
reasonable way because, AFAICT, that was never a design consideration.

There's an interesting parallel to English, which is arguably the most
complex and hideous language to ever exist. It didn't start out that
way, though. If you understand the evolution and influences, it
actually does make quite a bit of sense--just not if you try to
understand its modern form all at once in a vacuum.

> It's amusing to see how numb Intel users have become to the
> fact, they don't even consider it odd anymore.

That's because almost nobody ever _sees_ the ISA, and even those that do
generally only see it at the assembly level, not the actual binary
encoding. Writing an assembler (and, to a lesser extent, a compiler) is
obviously painful, but that's a one-time task for a handful of people,
not something the masses have to deal with.

> On Intel some
> intructions that are available in 16/32 bit mode (AAA comes to mind)
> don't work in 64 bit mode,

Well, they _did_ need to recover a sizeable chunk of opcode space, and
instructions that were rarely/never used anymore or that had redundant
encodings were obvious targets.

> you can't use registers in the wrong mode,
> and you can't link an executable that contains programs in different
> modes.

Nope. While that's a pain during the transitions, it's really not that
big a problem overall. Obviously, someone starting from scratch
wouldn't have designed it that way, but we can't rewrite history.

> Given IBM was there first in all cases, and did things seamlessly
> and elegantly (and their tech pubs are freely available online) there
> really isn't any excuse for Intel's consistent history of embarassing
> fuckups.

True, but it's not surprising given some of the details published
explaining how and why those fuckups happened. Most companies that
dysfunctional either learn from their mistakes or are destroyed by the
market, but Intel has (so far) managed to avoid doing either.

> ... nobody seems to have adopted [IBM's] hardware/software
> as a package philosophy except perhaps to a much less extent Sun with
> Solaris/SPARC, and that was also a very nice platform.

The conventional wisdom is that one company cannot be good at both, so
they focus on one and try to commoditize the other. IBM nearly imploded
in the 1980s by ignoring that, and many others (including Sun) followed
in their footsteps. IBM only survived by focusing on "services", i.e.
neither hardware nor software, which was a phenomenal shift for a
company that large--and a smaller company wouldn't have had the
resources to pull it off.

> Personally, I'm very sick of Intel's shitty "engineering" and I'm
> glad to see other companies and architectures make headway whenever
> they can.

If were really that "shitty", or purity of design actually mattered to
the market, then Intel would be long dead by now.

One could attribute Intel's success _today_ to their market position and
questionable tactics, but they _did_ have many larger competitors back
in the day and still managed to come out on top, so perhaps there's more
to success than ideological (or simply logical) purity.

S

--
Stephen Sprunk "God does not play dice." --Albert Einstein
CCIE #3723 "God is an inveterate gambler, and He throws the
K5SSS dice at every possible opportunity." --Stephen Hawking

[Paul A. Clayton]

On Tuesday, October 2, 2012 7:22:22 AM UTC-4, Stephen Sprunk wrote:
[snip]

> Well, the original ISA made a reasonable amount of sense back when it
> was designed, but there really wasn't any way to extend it in a
> reasonable way because, AFAICT, that was never a design consideration.
>
> There's an interesting parallel to English, which is arguably the most
> complex and hideous language to ever exist. It didn't start out that
> way, though. If you understand the evolution and influences, it
> actually does make quite a bit of sense--just not if you try to
> understand its modern form all at once in a vacuum.

The relative ease with which English can be extended--like x86--
may be one of its strengths. The relative lack of metadata in
words (even the mood and tense of verbs is often expressed in
part via "prefixes") facilitates using nouns as verbs and
adjectives (e.g.) and combined with the existing adoption of
words from other languages makes adopting (and creating) new
words easier. Like x86, I could wish that there was more
regularity (I am not certain how ambiguity should be handled;
I suspect the extreme of logical language is inappropriate).
There might even be negative effects of U.S. cultural
dominance with respect to the English language that are
analogous to the effects of Intel's dominance of x86.

[snip]

> The conventional wisdom is that one company cannot be good at both, so
> they focus on one and try to commoditize the other. IBM nearly imploded
> in the 1980s by ignoring that, and many others (including Sun) followed
> in their footsteps. IBM only survived by focusing on "services", i.e.
> neither hardware nor software, which was a phenomenal shift for a
> company that large--and a smaller company wouldn't have had the
> resources to pull it off.

Part of the success of x86 is probably due to the merchant
processor orientation. Vertical integration tends to hinder
competition and innovation. (One could even argue that Intel's
integration of manufacturing and processor design introduces
significant "artificial" competitive barriers.)

Vertical integration can reduce communication overhead within
an organization but tends to hinder communication with those
outside the organization. In large organizations,
communication can actually be hindered by the unification
when subdivisions perceive rewards as slices of a single pie
and the relative size of one's slice is of primary importance.
Having an external market-oriented regulator of rewards can
also encourage productive effort (rather than political
effort) and possibly reduce some discouraging effects of
failures from "external" circumstances (in a more tightly
organized system change seems less possible).

[Michael S]

On Oct 2, 1:22 pm, Stephen Sprunk <step...@sprunk.org> wrote:
> On 24-Sep-12 08:48, Anonymous wrote:
>
>
> That's because almost nobody ever _sees_ the ISA, and even those that do
> generally only see it at the assembly level, not the actual binary
> encoding.  Writing an assembler (and, to a lesser extent, a compiler) is
> obviously painful, but that's a one-time task for a handful of people,
> not something the masses have to deal with.
>

Writing x86 disassembler (and disassembling part of debugger) could be
painful.
Writing x86 assembler seem trivial.
Writing non-optimizing x86 compiler should be trivial too.
Writing optimizing x86 compiler could be painful due to semantic
issues (many ways of achieving the same result, not necessarily equal
speedwise), but encoding hardly matters.

[EricP]

Stephen Sprunk wrote:
>
> There's an interesting parallel to English, which is arguably the most
> complex and hideous language to ever exist. It didn't start out that
> way, though. If you understand the evolution and influences, it
> actually does make quite a bit of sense--just not if you try to
> understand its modern form all at once in a vacuum.

This is a quite good British documentary on this called
"The Adventure of English", 8 episodes of 50 minutes each.
It traces English from its roots in Friesland, Netherlands
1500 years ago to modern day.

http://watchdocumentary.com/view-adventure-of-english-serie-free-1-date.html

English basically grew by absorbing words from every culture
it came in touch with. e.g. color khaki from India.

Eric

[Terje Mathisen]

Michael S wrote:
> On Oct 2, 1:22 pm, Stephen Sprunk <step...@sprunk.org> wrote:
>> On 24-Sep-12 08:48, Anonymous wrote:
>>
>>
>> That's because almost nobody ever _sees_ the ISA, and even those that do
>> generally only see it at the assembly level, not the actual binary
>> encoding. Writing an assembler (and, to a lesser extent, a compiler) is
>> obviously painful, but that's a one-time task for a handful of people,
>> not something the masses have to deal with.
>>
>
> Writing x86 disassembler (and disassembling part of debugger) could be
> painful.

Disasm is pretty trivial, you only get into trouble if you try to
automatically determine where blocks of code start.

> Writing x86 assembler seem trivial.

This is actually a little bit harder than the disasm part, since there
are multiple ways to encode the same asm source.

> Writing non-optimizing x86 compiler should be trivial too.

It took Anders Hejlsberg 35 KB to write a screen editor, compiler,
linker and runtime library back around 1983.

> Writing optimizing x86 compiler could be painful due to semantic
> issues (many ways of achieving the same result, not necessarily equal
> speedwise), but encoding hardly matters.

See above: The only real problem with x86 compilation is to handle the
register pressure properly.

Recently automatic vectorization is probably where the real big gains
could/can be had.

[Stephen Fuld]

On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
> On 24-Sep-12 08:48, Anonymous wrote:
>> It would seem from Intel's other horrific blunders and foolish
>> missteps over the past decades they were and are relatively hostile
>> to outside influences and they seem to have gone out of their way
>> several times to shoot themselves in the foot.
>
> Pretty much _every_ ISA that Intel has ever deliberately designed has
> been a miserable failure. Their successes have been either accidents or
> a result of copying someone else.

Intel has had several major successes. The original 8080 arguably
started the personal computer revolution, obviously the X86, and don't
forget the 8051, which, by volume, swamps anything else around. Of
course, they have had many failures too, but so has everyone else. See
below.

Come on now. First of all, IBM wasn't first, Univac, or arguably ABC
was. Second of all, you are conveniently forgetting all of IBM's
mistakes. For examples, look at the System/1, the System/7, the System
32/34/36. Even in the PC world, remember the MCA bus, the PC Jr., etc.
Even the S/360 architecture has had significant mistakes. For
example, others have mentioned the 16 bit floating point. Also, I
regard the way the the addressing is set up with over half the available
addressing space taken up by the OS and shared memory, and exposing the
OS's internal addresses to the user program, thus limiting program size
and needing kludgy OS support to get around as a mistake. Don't get me
wrong, IBM has had some fantastic successes. But every company makes
mistakes. Some have enough successes in other products to withstand them.

> True, but it's not surprising given some of the details published
> explaining how and why those fuckups happened. Most companies that
> dysfunctional either learn from their mistakes or are destroyed by the
> market, but Intel has (so far) managed to avoid doing either.

Yes. Like IBM, they have had enough success in other areas to "cover"
their mistakes.

>> ... nobody seems to have adopted [IBM's] hardware/software
>> as a package philosophy except perhaps to a much less extent Sun with
>> Solaris/SPARC, and that was also a very nice platform.

All of the other mainframe companies did so. But it takes a huge amount
of resources to do both and those companies have been pushed to the
fringes of the computing world, or out of it altogether.

> The conventional wisdom is that one company cannot be good at both, so
> they focus on one and try to commoditize the other. IBM nearly imploded
> in the 1980s by ignoring that, and many others (including Sun) followed
> in their footsteps. IBM only survived by focusing on "services", i.e.
> neither hardware nor software, which was a phenomenal shift for a
> company that large--and a smaller company wouldn't have had the
> resources to pull it off.

IBM still makes a huge amount of money in their mainframe business. And
other companies have moved in the same direction, see for example Unisys.

>> Personally, I'm very sick of Intel's shitty "engineering" and I'm
>> glad to see other companies and architectures make headway whenever
>> they can.
>
> If were really that "shitty", or purity of design actually mattered to
> the market, then Intel would be long dead by now.
>
> One could attribute Intel's success _today_ to their market position and
> questionable tactics, but they _did_ have many larger competitors back
> in the day and still managed to come out on top, so perhaps there's more
> to success than ideological (or simply logical) purity.

Yup. Including "luck". IBM was originally favoring the 6800 for the
PC, but at the time, Motorola didn't have a part with an 8 bit
interface, which IBM felt it needed to keep system costs down.

You could argue that it was luck or that it was foresight on the part of
Intel to have developed the 8088.



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

[Quadibloc]

On Oct 2, 11:40 am, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

>   Even the S/360 architecture has had significant mistakes.  For
> example, others have mentioned the 16 bit floating point.

The what?

Ah, you meant *base-16* floating point. 32 bits or 64 bits in length,
though.

John Savard

[Stephen Fuld]

Yes. Sorry for the confusion.

[Joe Pfeiffer]

Stephen Fuld <SF...@alumni.cmu.edu.invalid> writes:

> On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
>> On 24-Sep-12 08:48, Anonymous wrote:
>>> It would seem from Intel's other horrific blunders and foolish
>>> missteps over the past decades they were and are relatively hostile
>>> to outside influences and they seem to have gone out of their way
>>> several times to shoot themselves in the foot.
>>
>> Pretty much _every_ ISA that Intel has ever deliberately designed has
>> been a miserable failure. Their successes have been either accidents or
>> a result of copying someone else.
>
> Intel has had several major successes. The original 8080 arguably
> started the personal computer revolution, obviously the X86, and don't
> forget the 8051, which, by volume, swamps anything else around. Of
> course, they have had many failures too, but so has everyone else.
> See below.

Original 8080 was a slight extension of the 8008, which was a Computer
Terminal Corporation (later known as Datapoint) ISA. x86 was an
accident -- it was a stopgap intended to fill in until the iAPX 432 was
ready. I don't know the history of the origin of the 8051, but two of
your examples make Stephen S.'s point.

<snip>

>> One could attribute Intel's success _today_ to their market position and
>> questionable tactics, but they _did_ have many larger competitors back
>> in the day and still managed to come out on top, so perhaps there's more
>> to success than ideological (or simply logical) purity.
>
> Yup. Including "luck". IBM was originally favoring the 6800 for the
> PC, but at the time, Motorola didn't have a part with an 8 bit
> interface, which IBM felt it needed to keep system costs down.

I've seen this claim (68000 actually) multiple times over the decades
(and repeated it many times, until challenged), but I have yet to find a
single piece of evidence that it is actually true. IBM did build a
laboratory computer (the IBM 9000 lab computer was 68000-based, and I
suspect is the foundation for the legend).

[Stephen Fuld]

On 10/2/2012 1:13 PM, Joe Pfeiffer wrote:
> Stephen Fuld <SF...@alumni.cmu.edu.invalid> writes:
>
>> On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
>>> On 24-Sep-12 08:48, Anonymous wrote:
>>>> It would seem from Intel's other horrific blunders and foolish
>>>> missteps over the past decades they were and are relatively hostile
>>>> to outside influences and they seem to have gone out of their way
>>>> several times to shoot themselves in the foot.
>>>
>>> Pretty much _every_ ISA that Intel has ever deliberately designed has
>>> been a miserable failure. Their successes have been either accidents or
>>> a result of copying someone else.
>>
>> Intel has had several major successes. The original 8080 arguably
>> started the personal computer revolution, obviously the X86, and don't
>> forget the 8051, which, by volume, swamps anything else around. Of
>> course, they have had many failures too, but so has everyone else.
>> See below.
>
> Original 8080 was a slight extension of the 8008, which was a Computer
> Terminal Corporation (later known as Datapoint) ISA. x86 was an
> accident -- it was a stopgap intended to fill in until the iAPX 432 was
> ready.

OK, but it was still designed by Intel.

> I don't know the history of the origin of the 8051, but two of
> your examples make Stephen S.'s point.
>
> <snip>
>
>>> One could attribute Intel's success _today_ to their market position and
>>> questionable tactics, but they _did_ have many larger competitors back
>>> in the day and still managed to come out on top, so perhaps there's more
>>> to success than ideological (or simply logical) purity.
>>
>> Yup. Including "luck". IBM was originally favoring the 6800 for the
>> PC, but at the time, Motorola didn't have a part with an 8 bit
>> interface, which IBM felt it needed to keep system costs down.
>
> I've seen this claim (68000 actually) multiple times over the decades
> (and repeated it many times, until challenged), but I have yet to find a
> single piece of evidence that it is actually true. IBM did build a
> laboratory computer (the IBM 9000 lab computer was 68000-based, and I
> suspect is the foundation for the legend).

See about page 17-18 at

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0CCUQFjAB&url=http%3A%2F%2Farchive.computerhistory.org%2Fresources%2Ftext%2FOral_History%2FMotorola_68000%2F102658164.05.01.acc.pdf&ei=A1BrUJPTIoGMiALG_oCIDw&usg=AFQjCNGstelPI0xnGv9rbGoi7u6JCNiEaw&sig2=GXh0aiDJQf_xdNCufl4NYw&cad=rjt


Sorry for the long URL. Firefox abbreviates it and I haven't figured
out how to get the URL of the PDF.

and

http://forwardthinking.pcmag.com/none/286228-why-the-ibm-pc-used-an-intel-8088

There is some dispute, but both give the availability of lower cost
peripherals as one of the reasons.

[Quadibloc]

On Oct 2, 2:56 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

> See about page 17-18 at
>

> http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=2&ved=0C...

>
> Sorry for the long URL.  Firefox abbreviates it and I haven't figured
> out how to get the URL of the PDF.

That would be

http://archive.computerhistory.org/resources/text/Oral_History/Motorola_68000/102658164.05.01.acc.pdf

...you just copy it out of the address bar of Firefox after it
resolves, and Firefox automatically adds the http:// in the clipboard.

John Savard

[Quadibloc]

On Oct 2, 12:57 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:

> Yes.  Sorry for the confusion.

No need to apologize, it _was_ a cheap shot, even if it was intended
to be helpful to others in avoiding confusion, and not out of
meanness.

Meanwhile, at

http://www.quadibloc.com/arch/per0101.htm

I'm setting computing back 50 years or thereabouts by attempting to
design a 360-like architecture, but using only 12 bits where the 360
used 16.

John Savard

[Michael S]

On Oct 2, 7:40 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:

> Michael S wrote:
>
> See above: The only real problem with x86 compilation is to handle the
> register pressure properly.

By today's standard TurboPascal can't be considered optimizing
compiler.

>
> Recently automatic vectorization is probably where the real big gains
> could/can be had.
>

Not really. Even the best compilers of today are still pretty dumb.
See, for example, this discussion:
http://www.realworldtech.com/forum/?threadid=120182&curpostid=120385
In particular, pay attention to Linus's comment that looks more
insightful than naive suggestions of the rest of us.

[Michael S]

On Oct 2, 7:40 pm, Stephen Fuld <SF...@alumni.cmu.edu.invalid> wrote:
>
> Intel has had several major successes.  The original 8080 arguably
> started the personal computer revolution, obviously the X86, and don't
> forget the 8051, which, by volume, swamps anything else around.  Of
> course, they have had many failures too, but so has everyone else.  See
> below.
>

Yes and more:

8096/196 was no worse than other "pure" 16-bitters (pure= not
attempting to address more than 64KWord in a single address space).
Arguably, nicer than many. It just was unfortunate to be 16-bit MCU.

i960 was not the cleanest 32-bit RISC around, but not too complicated
either. Certainly better than SPARC that Anonymous and Stephen Sprunk
are praising. It was also pretty successful in the intended market,
held crown of best-selling 32-or-more-bit RISC for several consecutive
years. It was killed in favor of ARM, but it seems to me this decision
had a lot more to do with Intel's internal politics than in relative
merits of the two ISAs or even with their relative strength in the
market. Back then ARM was not a juggernaut it is today.

Also, while 8086 could be considered an accident, but 80386 was
certainly designed for long-term success. And it has damn wisely
selected set of addressing modes which matters a lot more than
encoding ugliness that bothers Anonymous.

[John Levine]

>i960 was not the cleanest 32-bit RISC around, but not too complicated
>either.

I never understood the i860 and the i960.

The 860 had an exposed pipeline, so you could get fabulous performance
if you programmed it just right, and a really awful interrupt
architecture not unlike a DSP, but they sold it as a general purpose
CPU. The i960 was originally a general purpose design for BiiN, and
it had a lot of familiar features such as SPARC-like register windows,
but it ended up as an embedded chip. Huh?

--
Regards,
John Levine, jo...@iecc.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

[Quadibloc]

On Oct 2, 5:15 pm, Michael S <already5cho...@yahoo.com> wrote:

> i960 was not the cleanest 32-bit RISC around, but not too complicated
> either. Certainly better than SPARC that Anonymous and Stephen Sprunk
> are praising.

I thought that while the i960 had many very nice features, it had at
least one fatal flaw.

> Also, while 8086 could be considered an accident, but 80386 was
> certainly designed for long-term success. And it has damn wisely
> selected set of addressing modes which matters a lot more than
> encoding ugliness that bothers Anonymous.

There, you are quite right. Encoding ugliness is merely a matter of
aesthetics, and what matters is whether a chip can do the job.

Or, to be *more* precise, what _really_ matters is how much software
is out there for a given ISA, and compared to that, aesthetics is
small potatoes - only a chip that can't do the job nearly as well as
the competition would be a serious enough problem to cause a shift
away from a dominant software ecosystem.

I mean, it's not as if everyone who bought a PC instead of a Mac was
going to have to program in x86 assembler at any point in the life of
their system.

Compare that to the mainframe days where there would be a lot of
people programming in a given installation, some of whom might very
well be using assembly language. This placed constraints on the...
creativity... of ISA designers. So we got machines like the 360, to
which the 68000 was a successor - instead of the x86 and,
significantly worse yet, the Itanium.

That it seems impossible that mere mortals could program the Itanium
at length in assembly language without going mad was apparently not a
design concern - as it was never intended that they would need to. I
mean, we even have this language called "C" nowadays that you can do
even the most basic systems programming in. So your portable cross-
compiler compiles itself...

John Savard

[Michael S]

On Oct 3, 1:51 am, John Levine <jo...@iecc.com> wrote:
> >i960 was not the cleanest 32-bit RISC around, but not too complicated
> >either.
>
> I never understood the i860 and the i960.
>
> The 860 had an exposed pipeline, so you could get fabulous performance
> if you programmed it just right, and a really awful interrupt
> architecture not unlike a DSP, but they sold it as a general purpose
> CPU.

When they sold it as a general purpose CPU?
I never encountered i860 "in the wild" in role other than floating-
point DSP. Which it is.

> The i960 was originally a general purpose design for BiiN, and
> it had a lot of familiar features such as SPARC-like register windows,
> but it ended up as an embedded chip.  Huh?
>

Most variants of i960 had no on-chip FPU. Those that had were
relatively expensive and FPU itself was i486-class - i.e. subpar by
'92-'93 "workstation" standard. I think, by '92 even SPARC had faster
FPU.

So, at that time frame it was not suitable for role of main CPU for
Unix workstation.
As too why didn't they push it into workstations 2-3 years earlier,
when weak or no FPU was a norm - I don't know. May be they try by
didn't succeed? Pay attention that at the same time AMD didn't find
workstation vendor for 29K and Motorala didn't find anybody except
mode-dead-than-alive Data General for 88K, despite the later having no
obvious technical disadvantages. And MIPS was acquired by SGI soon
thereafter.

So, may be, back then workstation vendors considered full control of
CPU side a must?
And, may be, later developments proved that they were right? I mean,
the last "merchant" Unix architecture (HP-UX/IPF) is dying right now.
Even Solaris/SPARC, which is not in great shape either, is likely to
survive for longer. And the last one standing will be AIX/Power - the
most vertically-integrated of them all.

[Michael S]

On Oct 3, 2:04 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Oct 2, 5:15 pm, Michael S <already5cho...@yahoo.com> wrote:
>
> > i960 was not the cleanest 32-bit RISC around, but not too complicated
> > either. Certainly better than SPARC that Anonymous and Stephen Sprunk
> > are praising.
>
> I thought that while the i960 had many very nice features, it had at
> least one fatal flaw.
>
> > Also, while 8086 could be considered an accident, but 80386 was
> > certainly designed for long-term success. And it has damn wisely
> > selected set of addressing modes which matters a lot more than
> > encoding ugliness that bothers Anonymous.
>
> There, you are quite right. Encoding ugliness is merely a matter of
> aesthetics, and what matters is whether a chip can do the job.
>
> Or, to be *more* precise, what _really_ matters is how much software
> is out there for a given ISA, and compared to that, aesthetics is
> small potatoes - only a chip that can't do the job nearly as well as
> the competition would be a serious enough problem to cause a shift
> away from a dominant software ecosystem.

Well, I don't know whether it is true or not. VAX certainly had
dominant software ecosystem.
Few people that know more than me claim that VAX was *too* bad. Other
people that, too, know more than me, claim that with enough of will
power in DEC's upper management even VAX complexity was not an
insurmountable barrier.
Despite knowing less than those people I have opinion of my own which
is somewhere in the middle - VAX ISA was too bad to allow close to
leading edge performance in the first half of the 90s, but by 2nd half
of the 90s designers had enough of gates in their disposal (and
sufficiently rich bag of known tricks) to overcome majority of VAX
deficiencies.

>
> I mean, it's not as if everyone who bought a PC instead of a Mac was
> going to have to program in x86 assembler at any point in the life of
> their system.
>
> Compare that to the mainframe days where there would be a lot of
> people programming in a given installation, some of whom might very
> well be using assembly language. This placed constraints on the...
> creativity... of ISA designers. So we got machines like the 360, to
> which the 68000 was a successor - instead of the x86 and,
> significantly worse yet, the Itanium.

Well, I wouldn't call 68000 a successor to S/360. It is much more
complex even in its original form. With '020 extensions its complexity
is much closer to VAX than to S/360.

>
> That it seems impossible that mere mortals could program the Itanium
> at length in assembly language without going mad was apparently not a
> design concern - as it was never intended that they would need to.

Small-scale coding for Itanium in assembler is certainly possible and
I even heard about people that enjoyed the experience.
TI C6000 family, which is ideologically similar to IPF, even has tool
called Linear Assembler that is designed to make EPIC/VLIW assembler
coding more accessible to mortals.

[Quadibloc]

On Oct 2, 6:31 pm, Michael S <already5cho...@yahoo.com> wrote:
> and Motorala didn't find anybody except
> mode-dead-than-alive Data General for 88K,

On the other hand, the 68K went into the Apollo, the NeXT, and
workstations by Sun and Tektronix, the Macintosh and the Lisa at the
office computer end, and the Atari ST, the Amiga, and the Sinclair QL
at the home computer end.

Being a joy to work with once counted for something.

John Savard

[Quadibloc]

On Oct 2, 6:59 pm, Michael S <already5cho...@yahoo.com> wrote:

> Few people that know more than me claim that VAX was *too* bad. Other
> people that, too, know more than me, claim that with enough of will
> power in DEC's upper management even VAX complexity was not an
> insurmountable barrier.

> Well, I wouldn't call 68000 a successor to S/360. It is much more
> complex even in its original form. With '020 extensions its complexity
> is much closer to VAX than to S/360.

Raw complexity isn't too awful if the *basic* scheme of the ISA is
simple. It's when you can't begin by learning a reasonably simple and
yet reasonably complete subset of the ISA that there is a problem.

> Small-scale coding for Itanium in assembler is certainly possible and
> I even heard about people that enjoyed the experience.

I don't doubt that.

John Savard

[Quadibloc]

On Oct 2, 5:22 am, Stephen Sprunk <step...@sprunk.org> wrote:
> On 24-Sep-12 08:48, Anonymous wrote:

> > ... nobody seems to have adopted [IBM's] hardware/software
> > as a package philosophy except perhaps to a much less extent Sun with
> > Solaris/SPARC, and that was also a very nice platform.
>
> The conventional wisdom is that one company cannot be good at both, so
> they focus on one and try to commoditize the other.  IBM nearly imploded
> in the 1980s by ignoring that, and many others (including Sun) followed
> in their footsteps.  IBM only survived by focusing on "services", i.e.
> neither hardware nor software, which was a phenomenal shift for a
> company that large--and a smaller company wouldn't have had the
> resources to pull it off.

It is my opinion that the only conceivable reason for Oracle to have
bought Sun (unless they needed a massive tax write-off or a poison
pill) is that they're intending to follow IBM down this particular
road.

IBM is not what it once was, but this still seems like insanity. Now,
if *Intel* had bought *Oracle*, to make Itanium-based database
servers, we might have had something interesting. Although x86 Xeons
would have benefited more from Intel's economies of scale.

John Savard

[MitchAlsup]

On Tuesday, October 2, 2012 7:04:43 PM UTC-5, Quadibloc wrote:
> So we got machines like the 360, to which the 68000 was a successor

The 68K designers would point at the PDP-11 as their inspiration.

Mitch

[Stephen Sprunk]

On 02-Oct-12 12:40, Stephen Fuld wrote:
> On 10/2/2012 4:22 AM, Stephen Sprunk wrote:
>> On 24-Sep-12 08:48, Anonymous wrote:
>>> It would seem from Intel's other horrific blunders and foolish
>>> missteps over the past decades they were and are relatively
>>> hostile to outside influences and they seem to have gone out of
>>> their way several times to shoot themselves in the foot.
>>
>> Pretty much _every_ ISA that Intel has ever deliberately designed
>> has been a miserable failure. Their successes have been either
>> accidents or a result of copying someone else.
>
> Intel has had several major successes.

By accident, not by design.

> The original 8080 arguably started the personal computer revolution,

That ISA came from CTC, not designed by Intel.

> obviously the X86,

That ISA was a hack of CTC's 8080 ISA plus segmentation, which plagued
the PC world for two decades.

> and don't forget the 8051, which, by volume, swamps anything else
> around.

I don't know the history of that one.

>> One could attribute Intel's success _today_ to their market
>> position and questionable tactics, but they _did_ have many larger
>> competitors back in the day and still managed to come out on top,
>> so perhaps there's more to success than ideological (or simply
>> logical) purity.
>
> Yup. Including "luck".

Certain companies seem to be consistently lucky, while others seem to be
consistently unlucky. I suspect that's not a matter of random chance
but rather some hidden factor that simply appears to be "luck".

> IBM was originally favoring the 6800 for the PC, but at the time,
> Motorola didn't have a part with an 8 bit interface, which IBM felt
> it needed to keep system costs down.
>
> You could argue that it was luck or that it was foresight on the
> part of Intel to have developed the 8088.

Still, it shows that even if you credit Intel with the design of the
8086, commercial success didn't come until IBM told them to make an
8-bit version--the opposite of where Intel's designers were headed.

[Michael S]

Nah, I don't think it has much to do with joy (BTW, according to my
understanding, up until '030, 68K external interfaces were more like
nightmare to system HW designers rather than joy).

All 68K design wins you mentioned happened 5-6 years earlier than the
period we are talking about.
First, workstation companies (except HP) were smaller.
Second, RISC ideas were less widespread.
Third, (not sure) what's today called foundries either did not exist
or just started to appear.
All this factors together made in-house development of workstation CPU
a riskier endeavor.

So they looked for off-the-shelf part. And 68K was pretty much the
only game in town that
a) did not consist of too many chips
b) had 32-bit address space
c) came from big, reliable vendor that, at the same time, was unlikely
to become a competitor.

Both i386 and NS 32K were late to the game. And even despite being
late i386 manged to score couple of wins at Sun.

[Michael S]

On Oct 3, 4:18 am, Stephen Sprunk <step...@sprunk.org> wrote:
>
> Still, it shows that even if you credit Intel with the design of the
> 8086, commercial success didn't come until IBM told them to make an
> 8-bit version--the opposite of where Intel's designers were headed.
>

Wasn't it other way around? I.e. 8088 was either ready or close to
ready when IBM started to shop for engine for a PC?

[Michael S]

On Oct 3, 4:18 am, Stephen Sprunk <step...@sprunk.org> wrote:

> On 02-Oct-12 12:40, Stephen Fuld wrote:
>
>
> > The original 8080 arguably started the personal computer revolution,
>
> That ISA came from CTC, not designed by Intel.
>

8080 was source-code compatible to 8008 (which ISA was designed by
CTC), but not binary compatible.

[John Levine]

>> Still, it shows that even if you credit Intel with the design of the
>> 8086, commercial success didn't come until IBM told them to make an
>> 8-bit version--the opposite of where Intel's designers were headed.
>
>Wasn't it other way around? I.e. 8088 was either ready or close to
>ready when IBM started to shop for engine for a PC?

That's certainly the way I heard it. The PC was originally a Z-80
design, which they switched fairly late in the game to an 8088 when
they believed that Intel could provide enough of them. The data path
was still 8 bits so other than adding more address bits they could
keep the same bus and peripheral interfaces.

R's,
John

[Stephen Fuld]

On 10/2/2012 5:04 PM, Quadibloc wrote:

> Compare that to the mainframe days where there would be a lot of
> people programming in a given installation, some of whom might very
> well be using assembly language. This placed constraints on the...
> creativity... of ISA designers.

Really??? We had 36 bit word addressable machines (Univac), 60 bit word
addressable machines (CDC), decimal machines (Burroughs Medium systems),
machines where the ISA level was essentially hidden from all programmers
(i.e. there was no assembler) (Burroughs large scale systems), and
others (I am not familiar with Honeywell's nor NCR's systems. It seems
there were far more different ISAs then than now.

[Stephen Fuld]

On 10/2/2012 7:18 PM, Stephen Sprunk wrote:

snip

> Still, it shows that even if you credit Intel with the design of the
> 8086, commercial success didn't come until IBM told them to make an
> 8-bit version--the opposite of where Intel's designers were headed.

According to the references I gave above, Intel already had an 8 bit
interface designed. IBM didn't tell them to design something new; they
chose an option that Intel had already provided.

[Brian Drummond]

On Wed, 03 Oct 2012 04:30:16 +0000, John Levine wrote:

>>> Still, it shows that even if you credit Intel with the design of the
>>> 8086, commercial success didn't come until IBM told them to make an
>>> 8-bit version--the opposite of where Intel's designers were headed.
>>
>>Wasn't it other way around? I.e. 8088 was either ready or close to ready
>>when IBM started to shop for engine for a PC?
>
> That's certainly the way I heard it. The PC was originally a Z-80
> design, which they switched fairly late in the game to an 8088 when they
> believed that Intel could provide enough of them. The data path was
> still 8 bits so other than adding more address bits they could keep the
> same bus and peripheral interfaces.

The Intel databook I didn't make off with from the BBC would bear that
out, the 8088 was part of the original plan, between the 8087 FP
coprocessor and 8089 I/O coprocessor (did they ever actually make any of
those? I only ever saw datasheets for it)

Seems to me Intel's success has come from listening and adapting to what
the market has done with its existing products. Putting ideas out there
but being ready to drop them immediately the market went elsewhere, but -
crucially - making sure that the adaptations didn't screw (the bulk of)
existing customers. (though they dropped the CMOS version of the 8748,
dammit!)

- Brian

[Terje Mathisen]

Michael S wrote:
> On Oct 2, 7:40 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>> Michael S wrote:
>>
>> See above: The only real problem with x86 compilation is to handle the
>> register pressure properly.
>
> By today's standard TurboPascal can't be considered optimizing
> compiler.

Even by 1983 standards, TurboPascal was never an optimizing compiler,
and I used it purely as an example of a dumb but correct compiler. I.e.
something really tiny that actually did work.

>>
>> Recently automatic vectorization is probably where the real big gains
>> could/can be had.
>>
>
> Not really. Even the best compilers of today are still pretty dumb.

Michael, "don't teach your grandmother to suck eggs"! :-)

I have made a living out of beating compilers by 2X to 5X for the last
30 years, I probably know more ways they tend to mess up than most.

The fact is still that for well-written C code, it is quite often
possible to structure it in such a way that your target compiler will
turn it into something which is at least close to optimal asm.

> See, for example, this discussion:
> http://www.realworldtech.com/forum/?threadid=120182&curpostid=120385

OK, here we're talking 17%, not 2X or more.

Why are you using purely scalar code for a dot-product?
...
OK, now I've read a bunch more posts in that thread, and it turns out
your example is just that: A synthetic example where you explicitly use
scalar code for a vector problem, and then you complain that the
compiler ends up with code that is "3-5%" slower than it should have been.

> In particular, pay attention to Linus's comment that looks more
> insightful than naive suggestions of the rest of us.
>

Linus has obviously spent quite a lot of time staring at compiler
output, while trying to chase down regular bugs, code generation bugs or
even hw bugs.

As he wrote, compilers aren't even attempting to understand what a piece
of code is actually trying to accomplish.

See above where I wrote that it is often possible to rewrite your C code
in such a way that it is still portable, but your target compiler will
take that source and (more or less blindly) turn it into near-optimal
machine code.

If getting 80-95% of light speed isn't good enough for you, you
obviously need to switch to asm instead of complaining about how generic
compiler X is missing a few tricks.

Terje
PS. When I was asked to optimize one of the AES candidates (DFC from
CERN) the reference C code ran at one third the speed of the fast
entrants, which included the eventual winner, Rijndael.

A week later we got that 3X speedup, pulling out all the tricks we knew
about and inventing one or two new ones, but only after doing a full
unroll of all 8 iterations of the core algorithm (which freed up the
loop counter register), manually scheduling all operations etc.

I also found a tweak which resulted in a 2-5% slowdown, but which made
the timing of the entire algorithm completely key-independent, so that
an attacker would never be able to use timing analysis to pull out
(partial) key bits.

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

[Anton Ertl]

Quadibloc <jsa...@ecn.ab.ca> writes:
>I think that it is exactly how you first phrased it, and that
>something influenced with the IBM 360 was the PDP-11.
>
>The 6502 and the 8080 even tried to compare their architectures to the
>PDP-11 in advertising.

I thought about this some more. There is one thing that is
counterevidence to this theory: byte order.

S/360: big-endian
PDP-11: little-endian
6800 (parent of 6502): big-endian

Now one could explain that by architects not caring much about
compatibility with the byte order of the systems that influenced them
(and the little-endian 6502 might be cited as example of that), but
that does not sound very plausible to me (and the 6502 is just the
exception that proves the rule):

Nobody switches byte order when doing another implementation of an
existing architecture, so I don't expect people to choose the other
byte order when they let one architecture be influenced by another one
or try to compete with it. As for advertising, it usually does not
tell us anything about design decisions, and when it claims to do it,
it's highly suspicious.

- anton
--
M. Anton Ertl Some things have to be seen to be believed
an...@mips.complang.tuwien.ac.at Most things have to be believed to be seen
http://www.complang.tuwien.ac.at/anton/home.html

[Michael S]

On Oct 3, 11:05 am, Terje Mathisen <"terje.mathisen at tmsw.no">

wrote:
> Michael S wrote:
> > On Oct 2, 7:40 pm, Terje Mathisen <"terje.mathisen at tmsw.no"> wrote:
>
> >> Recently automatic vectorization is probably where the real big gains
> >> could/can be had.
>
> > Not really. Even the best compilers of today are still pretty dumb.
>
> Michael, "don't teach your grandmother to suck eggs"! :-)
>
> I have made a living out of beating compilers by 2X to 5X for the last
> 30 years, I probably know more ways they tend to mess up than most.
>
> The fact is still that for well-written C code, it is quite often
> possible to structure it in such a way that your target compiler will
> turn it into something which is at least close to optimal asm.
>

And the fact, that it takes very qualified effort, suggests exactly
what I said - there are many not-that-low-hanging-but-sweet fruits
apart from grail of automatic vectorization.

> > See, for example, this discussion:
> >http://www.realworldtech.com/forum/?threadid=120182&curpostid=120385
>
> OK, here we're talking 17%, not 2X or more.
>
> Why are you using purely scalar code for a dot-product?
> ...
> OK, now I've read a bunch more posts in that thread, and it turns out
> your example is just that: A synthetic example where you explicitly use
> scalar code for a vector problem,

This variant of the problem is vectorizable. Slightly different
variant of the same problem, that is going to be important of us in
the near future, is much harder to vectorize, if at all possible. At
least unless Haswell gather instructions performs much better than I
expect it to perform. So it's not 100% synthetic.

> and then you complain that the compiler ends up with code that is "3-5%" slower than it should have been.

No, AVX path should have been 3-5% faster than SSE path, but ended up
17% slower. So overall it is 20-22% slower than what it should have
been.
And compiler's miss is exactly due to ISA problem (in pessimist's
view, optimist will say "opportunity") that I mentioned above - there
are several way of achieving the same result and it's far from obvious
which way is the fastest.

>
> > In particular, pay attention to Linus's comment that looks more
> > insightful than naive suggestions of the rest of us.
>
> Linus has obviously spent quite a lot of time staring at compiler
> output, while trying to chase down regular bugs, code generation bugs or
> even hw bugs.
>
> As he wrote, compilers aren't even attempting to understand what a piece
> of code is actually trying to accomplish.
>
> See above where I wrote that it is often possible to rewrite your C code
> in such a way that it is still portable, but your target compiler will
> take that source and (more or less blindly) turn it into near-optimal
> machine code.

And then comes the next version of compiler and screws things in a new
and inventive way. See Anton Ertl's rants from couple of months ago.

>
> If getting 80-95% of light speed isn't good enough for you,

Practically, 80% is good enough for me. I want 100% mostly for
artist's satisfaction.

> you
> obviously need to switch to asm instead of complaining about how generic
> compiler X is missing a few tricks.

The problem, in this particular case, and in many other cases, is not
a compiler that is missing a few tricks, but a compiler that is
knowing a few tricks too many.

As to switching to asm - I can do it, but I know many otherwise
perfectly good programmers that don't posses this particular set of
skills.
Besides, even I, despite being sufficiently crazy to spend a day or
three coding/testing this kernel in asm, even I am too pragmatic to
actually ship asm variant in production code for a gain of mere 20%.

[Michael S]

On Oct 3, 3:21 am, Quadibloc <jsav...@ecn.ab.ca> wrote:
> On Oct 2, 5:22 am, Stephen Sprunk <step...@sprunk.org> wrote:
>
> > On 24-Sep-12 08:48, Anonymous wrote:
> > > ... nobody seems to have adopted [IBM's] hardware/software
> > > as a package philosophy except perhaps to a much less extent Sun with
> > > Solaris/SPARC, and that was also a very nice platform.
>
> > The conventional wisdom is that one company cannot be good at both, so
> > they focus on one and try to commoditize the other.  IBM nearly imploded
> > in the 1980s by ignoring that, and many others (including Sun) followed
> > in their footsteps.  IBM only survived by focusing on "services", i.e.
> > neither hardware nor software, which was a phenomenal shift for a
> > company that large--and a smaller company wouldn't have had the
> > resources to pull it off.
>
> It is my opinion that the only conceivable reason for Oracle to have
> bought Sun (unless they needed a massive tax write-off or a poison
> pill) is that they're intending to follow IBM down this particular
> road.

"Sun" != shrinking SPARC hardware busyness.

Sun owned Solaris, which happens to be unpopular, but very solid and
performant x86-64 OS.
Sun owned ZFS - modern influential filesystem
Sun owned Java as well as 2 out of 3 leading enterprise JVMs (Sun's
own Hot Spot and BEA JRockit).
Sun owned the rest of BEA middleware portfolio.
Probably most important of all, Sun owned MySQL

Besides, Sun Microsystems was really really cheap, esp. considering
its material assets and cash reserves.

>
> IBM is not what it once was, but this still seems like insanity. Now,
> if *Intel* had bought *Oracle*, to make Itanium-based database
> servers, we might have had something interesting. Although x86 Xeons
> would have benefited more from Intel's economies of scale.
>

"if *Intel* had bought *Oracle*" by now sounds like rather funny idea.
Intel and Oracle are about the same size, by nearly all measures,
including, most importantly, net income.

[Quadibloc]

On Oct 2, 9:16 pm, Michael S <already5cho...@yahoo.com> wrote:

> Wasn't it other way around? I.e. 8088 was either ready or close to
> ready when IBM started to shop for engine for a PC?

Indeed; Motorola didn't have the 68008 around, ultimately used in the
Sinclair QL, until much later.

John Savard

[Quadibloc]

On Oct 3, 8:52 am, Michael S <already5cho...@yahoo.com> wrote:

> "if *Intel* had bought *Oracle*" by now sounds like rather funny idea.
> Intel and Oracle are about the same size, by nearly all measures,
> including, most importantly, net income.

Oh. In that case, it is not entirely madness for Oracle to be trying
to compete head-to-head with IBM.

Sun has many assets; some people had thought that Java would be the
future of computing, for example. But spending money to squelch an
open-source competitor is a waste of money, since it can be forked. (I
assume the MySQL code, even if it's more efficient than Postgres code,
is not something Oracle needed to buy so it could incorporate it into
its proprietary products without licensing it under the GPL - it
wasn't running rings around Oracle or anything like that, was it?)

But when I tried to think about what could possibly relate to Oracle's
core business, the idea of SPARC-based hardware running Oracle
databases to head off against IBM hardware running IBM databases made
a sort of sense.

However, shortly *after* Oracle bought Sun, Intel went and brought out
the EX series of Xeon chips, so that RAS features, heretofore only
available from Intel on the Itanium (which many fear could someday be
orphaned) made it to the x86 platform.

My reaction at the time, which I see little reason to change, is that
*that* meant that Oracle had wasted its money. (SPARC-based chips from
Sun had already had RAS features, making them applicable to such a
plan.)

However, with Oracle so big, and Sun so small, I suppose it can
survive the mistake - if Sun was a bargain, Oracle can always spin it
off as a tiny cash cow division, for example, without distracting from
corporate focus.

John Savard

[Terje Mathisen]

Michael S wrote:
> On Oct 3, 11:05 am, Terje Mathisen <"terje.mathisen at tmsw.no">

>> If getting 80-95% of light speed isn't good enough for you,
>
> Practically, 80% is good enough for me. I want 100% mostly for
> artist's satisfaction.
>
>> you
>> obviously need to switch to asm instead of complaining about how generic
>> compiler X is missing a few tricks.
>
> The problem, in this particular case, and in many other cases, is not
> a compiler that is missing a few tricks, but a compiler that is
> knowing a few tricks too many.
>
> As to switching to asm - I can do it, but I know many otherwise
> perfectly good programmers that don't posses this particular set of
> skills.
> Besides, even I, despite being sufficiently crazy to spend a day or
> three coding/testing this kernel in asm, even I am too pragmatic to
> actually ship asm variant in production code for a gain of mere 20%.
>

Good!
:-)

Terje

[MitchAlsup]

The 68008 was still on the drawing boards (i.e. pre-tapeout) and was
projected to be 5 months later than the 8088 when the decision to "go"
was made.

The decision was based on availability and the lower cost of attaching
said processor to desired perifferals.

Mitch

[Walter Banks]

Stephen Sprunk wrote:

>
> > and don't forget the 8051, which, by volume, swamps anything else
> > around.
>
> I don't know the history of that one.
>

It was intel John Wharton, I have a copy somewhere of the 8051
sketches he made over dinner that eventually led to the 8051. He did
a presentation at one of the (in)famous Asilomar thursday night
presentations one year describing the 8051 development.

Walter Banks
Byte Craft Limited

[Walter Banks]

Terje Mathisen wrote:

> I have made a living out of beating compilers by 2X to 5X for the last
> 30 years, I probably know more ways they tend to mess up than most.
>
> The fact is still that for well-written C code, it is quite often
> possible to structure it in such a way that your target compiler will
> turn it into something which is at least close to optimal asm.
>

> ? See, for example, this discussion:
> ? http://www.realworldtech.com/forum/?threadid=120182?curpostid=120385

>
> OK, here we're talking 17%, not 2X or more.
>
> Why are you using purely scalar code for a dot-product?
> ...
> OK, now I've read a bunch more posts in that thread, and it turns out
> your example is just that: A synthetic example where you explicitly use
> scalar code for a vector problem, and then you complain that the
> compiler ends up with code that is "3-5%" slower than it should have been.
>

> ? In particular, pay attention to Linus's comment that looks more
> ? insightful than naive suggestions of the rest of us.
> ?

> Linus has obviously spent quite a lot of time staring at compiler
> output, while trying to chase down regular bugs, code generation bugs or
> even hw bugs.
>
> As he wrote, compilers aren't even attempting to understand what a piece
> of code is actually trying to accomplish.
>
> See above where I wrote that it is often possible to rewrite your C code
> in such a way that it is still portable, but your target compiler will
> take that source and (more or less blindly) turn it into near-optimal
> machine code.
>
> If getting 80-95% of light speed isn't good enough for you, you
> obviously need to switch to asm instead of complaining about how generic
> compiler X is missing a few tricks.
>
> Terje

Pulling some of your comments out of context. One of the effects of
open source development tools is the technology they use is dated.
The open source tools cherry pick customers that compiler performance
doesn't significantly matter. Saying that is not to restart the argument
of commercial vs open source. The effect is the available resources
to continue to extend our tools is limited by the potential customer
base that would use and pay for the tools.

I agree with many (most) of your comments about compiler technology.
There is another comment on asm and that is just using asm will not
add to application performance, it takes an exceptional asm
programmer to get the performance you are describing. Personally
I am interested in details of asm tricks to improve code generation
and application development. The fact that it is possible reflects on
the state of compilers where computing processor power is essentially
free.

We have implemented strategy passes to at least understand data
flow in application code. For the processors that we support I can
write (and prove) that a C program will equal or better metrics that
any asm program for the same processor. The only compiler intrinsics
needed is access to the condition codes in our compilers. There are
a lot of simple things that compilers in general don't do for example
is the whole ISA being used and is instruction limitations implemented
as part of the code generator.

In part development language research needs to move from the current
parsing and fragment code generation for the tools to move forward.

Regards

[Robert Swindells]

On Wed, 03 Oct 2012 08:05:12 +0000, Brian Drummond wrote:

> The Intel databook I didn't make off with from the BBC would bear that
> out, the 8088 was part of the original plan, between the 8087 FP
> coprocessor and 8089 I/O coprocessor (did they ever actually make any of
> those? I only ever saw datasheets for it)

The 8089 was used in the Apricot PC.