[TUHS] SPARC is CRAPS spelled backwards.

[TUHS] SPARC is CRAPS spelled backwards.

[Don Hopkins]

[-- Attachment #1: Type: text/plain, Size: 277 bytes --]

Its register windows have spilled out into the SCRAP heap of history.
But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST PAST. 
It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST. 
It can create a CAT SOPRANIST with a CASTRATO SNIP.

-Don


[-- Attachment #2: Type: text/html, Size: 897 bytes --]

Re: [TUHS] SPARC is CRAPS spelled backwards.

[A. P. Garcia]

[-- Attachment #1: Type: text/plain, Size: 1028 bytes --]

On Sun, Sep 23, 2018, 2:37 PM Don Hopkins <don@donhopkins.com> wrote:

> Its register windows have spilled out into the SCRAP heap of history.
> But to its credit, the SPARCSTATION represents PANTISOCRACY with NO RACIST
> PAST.
> It ROASTS CATNIP for SATANIC SPORT with no PARTISAN COST.
> It can create a CAT SOPRANIST with a CASTRATO SNIP.
>
In trying to steer this word salad towards some semblance of meaningful
discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
seems to be heading in that direction. Is RISC dead? Not at all. ARM is
doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
now, as even the current x86 processors have adopted many design features
that originated in RISC research.

The saddest thing about the death of SPARC, in my opinion, is that it
likely also means the death of the most advanced OS with "true" UNIX roots.
CDDL was ostensibly chosen to prevent Linux from cannibalizing the best
parts of Solaris. But it only seems to have slowed that down.

[-- Attachment #2: Type: text/html, Size: 2002 bytes --]

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Paul Winalski]

On 9/23/18, A. P. Garcia <a.phillip.garcia@gmail.com> wrote:
>
> In trying to steer this word salad towards some semblance of meaningful
> discussion, is SPARC dead? Practically, yes, I would say so. Or at least it
> seems to be heading in that direction. Is RISC dead? Not at all. ARM is
> doing quite well, and the old "CISC vs RISC" thing seems to be a non-issue
> now, as even the current x86 processors have adopted many design features
> that originated in RISC research.

In general, a CISC instruction set encoding can express the same
algorithm more compactly than a RISC instruction set.  Once CISC
technology solved the instruction pipelining and decoding problem, it
gained an advantage over RISC architectures such as Alpha because the
instruction set stream was less verbose.  Modern x86 designs have a
bit of logic stuck in one corner that translates the x86 instruction
stream into a string of RISC-style micro-operations.  The cores
execute the micro-ops.  Micro-op sequences can be cached, so the
translation is done only once for loops.  The result is, as it were,
the best of both worlds--the compactness of a CISC instruction stream
and the simpler and faster circuitry of RISC.

-Paul W.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Tony Finch]

Paul Winalski <paul.winalski@gmail.com> wrote:
>
> In general, a CISC instruction set encoding can express the same
> algorithm more compactly than a RISC instruction set.  Once CISC
> technology solved the instruction pipelining and decoding problem, it
> gained an advantage over RISC architectures such as Alpha because the
> instruction set stream was less verbose.

It's more subtle than that, I think. One of the best contributions to this
discussion was John Mashey's classic comp.arch article (which I originally
read in 1994, I think) -

https://yarchive.net/comp/risc_definition.html

What is striking about it is that the two dominant architectures now are
(very roughly) the least CISCy CISC and the least RISCy RISC. In
particular x86 did not go in for elaborate addressing modes and highly
orthogonal instruction sets that allow you to use the elaborate addressing
modes multiple times in one instruction. (Compare it with later 68Ks, for
contrast.) So the translation to RISC-style micro-ops does not end up with
ridiculously long dependency chains within most instructions.

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Shannon: South 3 or 4, increasing 5 to 7, perhaps gale 8 later. Moderate,
becoming rough, then very rough later in far northwest. Fair then occasional
rain. Good, becoming moderate, occasionally poor.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 1276 bytes --]

On 2018-Sep-23 17:17:35 -0400, Paul Winalski <paul.winalski@gmail.com> wrote:
>In general, a CISC instruction set encoding can express the same
>algorithm more compactly than a RISC instruction set.  Once CISC
>technology solved the instruction pipelining and decoding problem, it
>gained an advantage over RISC architectures such as Alpha because the
>instruction set stream was less verbose.

RISC architectures have another advantage that instructions are always
aligned on known boundaries (typically 2 or 4 bytes).  This simplifies
the logic around (pre-)fetching instructions.

>Modern x86 designs have a
>bit of logic stuck in one corner that translates the x86 instruction
>stream into a string of RISC-style micro-operations.

Where "modern" is "this century".

...
>the best of both worlds--the compactness of a CISC instruction stream
>and the simpler and faster circuitry of RISC.

In the specific case of x86, I would dispute that.  The various warts in the
x86 instruction set and "architecture" mean that x86 code density is
relatively low and on a par with SPARC code.  I agree that the overall
performance is impressive but that is more a measure of the abilities of
Intel's engineers than the overall approach.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Paul Winalski]

On 9/24/18, Peter Jeremy <peter@rulingia.com> wrote:
>
> In the specific case of x86, I would dispute that.  The various warts in
> the
> x86 instruction set and "architecture" mean that x86 code density is
> relatively low and on a par with SPARC code.  I agree that the overall
> performance is impressive but that is more a measure of the abilities of
> Intel's engineers than the overall approach.

No doubt about it--x86 instruction encoding is butt-ugly and wasteful,
due to the need for backward compatibility with what was originally an
8-bit architecture.  Does SPARC have the vector instructions that have
been added to x86 over the years?

-Paul W.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Arthur Krewat]

On 9/24/2018 4:20 PM, Paul Winalski wrote:
> No doubt about it--x86 instruction encoding is butt-ugly and wasteful,
> due to the need for backward compatibility with what was originally an
> 8-bit architecture.  Does SPARC have the vector instructions that have
> been added to x86 over the years?
The 8086 was the first of the "x86" line, which was 16-bit, although 
it's I/O was more 8080-ish if I recall correctly. The 8088 was an 8-bit 
data bus, granted, but having done both 8080 and 8086+ assembler, you 
couldn't really tell the difference, programming-wise between the 8086 
and the 8088, 16-bit registers, and all.

Cutting costs, as always, IBM opted for the 8088, which allowed them to 
use an 8085-style I/O architecture.

Also, granted, to this day you can still use only 8-bits of a register: 
MOV AL,0x80

art k.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 1395 bytes --]

On 2018-Sep-24 16:45:13 -0400, Arthur Krewat <krewat@kilonet.net> wrote:
>The 8086 was the first of the "x86" line, which was 16-bit, although 
>it's I/O was more 8080-ish if I recall correctly.

The 8086/8088 bus was designed to be similar to the 8085 to allow 8080/8085
peripherals to support 8086 systems.  This saved Intel the effort of
developing a new range of support peripherals and made it quicker for
vendors to build 8086 systems because they didn't need to wait for the
peripheral chips.  There are still 8080 support chips - 8253, 8257, 8259 -
embedded in PC Southbridge chips.

>The 8088 was an 8-bit 
>data bus, granted, but having done both 8080 and 8086+ assembler, you 
>couldn't really tell the difference, programming-wise between the 8086 
>and the 8088, 16-bit registers, and all.

This was deliberate - the 8080 was an upgraded 8008 and Intel made the 8086
similar enough to allow automated ASM translation.  It seems highly likely
that the undocumented 8085 opcodes were undocumented because they weren't
readily translatable to 8086.

>Cutting costs, as always, IBM opted for the 8088, which allowed them to 
>use an 8085-style I/O architecture.

An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
that the IBM 5150 was intentionally crippled to ensure it didn't compete with
IBM's low-end minis.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Lars Brinkhoff]

Peter Jeremy wrote:
> the 8080 was an upgraded 8008

Also note the 8008 instruction set originated at Compuer Terminal
Corporation (later Datapoint), for use as a text terminal controller.
I'd say it's an OK design for that purpose...

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Theodore Y. Ts'o]

On Wed, Sep 26, 2018 at 06:46:20AM +0000, Lars Brinkhoff wrote:
> Peter Jeremy wrote:
> > the 8080 was an upgraded 8008
> 
> Also note the 8008 instruction set originated at Compuer Terminal
> Corporation (later Datapoint), for use as a text terminal controller.
> I'd say it's an OK design for that purpose...

That's not that only CPU for which this was true.  The IBM PC/RT
(e.g., the 6150) CPU was originally designed to be used as a
typewriter controller.  It was a RISC design which was approximately 3
times faster than a Microvax, which meant that it was quite popular
for students using MIT's Project Athenna who needed to run Scribe or
TeX/LaTeX.  :-)

					- Ted

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Paul Winalski]

On 9/26/18, Theodore Y. Ts'o <tytso@mit.edu> wrote:
>
> That's not that only CPU for which this was true.  The IBM PC/RT
> (e.g., the 6150) CPU was originally designed to be used as a
> typewriter controller.

The CPU in the IBM 5100 was a 16-bit processor originally designed for
use in System/370 I/O peripheral controllers.

-Paul W.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Henry Bent]

[-- Attachment #1: Type: text/plain, Size: 520 bytes --]

On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter@rulingia.com> wrote:

>
> An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>

Did the 5150 have a UNIX available anywhere near its launch date?   I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?

-Henry

[-- Attachment #2: Type: text/html, Size: 815 bytes --]

[TUHS] Fwd: Re: SPARC is CRAPS spelled backwards.

[William Pechter]

Should have copied the list... 

-----Original Message-----
From: William Pechter <pechter@gmail.com>
To: Henry Bent <henry.r.bent@gmail.com>
Sent: Wed, 26 Sep 2018 11:59
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.

There was Xenix-86 which ran on the AT&T 6300, and IBM PC/XT.  I ran it on an 8MHz NEC V30 cpu on the 6300.  I would love to install it on my Panasonic Sr. Partner but lost the install key. 

-----Original Message-----
From: Henry Bent <henry.r.bent@gmail.com>
To: TUHS main list <tuhs@minnie.tuhs.org>
Sent: Wed, 26 Sep 2018 11:45
Subject: Re: [TUHS] SPARC is CRAPS spelled backwards.

On Wed, 26 Sep 2018 at 02:21, Peter Jeremy <peter@rulingia.com> wrote:

>
> An 8-bit memory bus means half as many RAM chips and buffers.  Keep in mind
> that the IBM 5150 was intentionally crippled to ensure it didn't compete
> with
> IBM's low-end minis.
>

Did the 5150 have a UNIX available anywhere near its launch date?   I know
that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
not clear to me whether Xenix ever supported the original PC; were there
other early porting efforts?

-Henry

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Donald ODona]

At 26 Sep 2018 15:45:25 +0000 (+00:00) from Henry Bent <henry.r.bent@gmail.com>:
> Did the 5150 have a UNIX available anywhere near its launch date?   I know
> that it had DOS, CP/M-86, and the UCSD p-System relatively early on.  It's
> not clear to me whether Xenix ever supported the original PC; were there
> other early porting efforts?
read more here:
http://www.softpanorama.org/People/Torvalds/Finland_period/xenix_microsoft_shortlived_love_affair_with_unix.shtml

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Tony Finch]

Peter Jeremy <peter@rulingia.com> wrote:

> In the specific case of x86, I would dispute that.  The various warts in
> the x86 instruction set and "architecture" mean that x86 code density is
> relatively low and on a par with SPARC code.

This paper has a nice survey of instruction set densities, which very much
disagrees with your statement:

http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

Tony.
-- 
f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/
Dogger, Fisher, German Bight, Humber: West or northwest 4 backing southwest 5
to 7, occasionally gale 8 later except in Humber. Slight or moderate becoming
moderate or rough, then very rough later in Fisher. Showers. Good.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Larry McVoy]

On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
> Peter Jeremy <peter@rulingia.com> wrote:
> 
> > In the specific case of x86, I would dispute that.  The various warts in
> > the x86 instruction set and "architecture" mean that x86 code density is
> > relatively low and on a par with SPARC code.
> 
> This paper has a nice survey of instruction set densities, which very much
> disagrees with your statement:
> 
> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

That's a neat paper, I like it, thanks for the pointer.  I'm curious
why Peter thought what he thought, my guess would have been more like
what the paper showed, but that was a "hand optimized assembly", maybe
the compilers aren't that good?  I dunno, Peter, care to comment?

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Peter Jeremy]

[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]

On 2018-Sep-25 08:01:52 -0700, Larry McVoy <lm@mcvoy.com> wrote:
>On Tue, Sep 25, 2018 at 11:00:37AM +0100, Tony Finch wrote:
>> Peter Jeremy <peter@rulingia.com> wrote:
>> 
>> > In the specific case of x86, I would dispute that.  The various warts in
>> > the x86 instruction set and "architecture" mean that x86 code density is
>> > relatively low and on a par with SPARC code.
>> 
>> This paper has a nice survey of instruction set densities, which very much
>> disagrees with your statement:
>> 
>> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf
>
>That's a neat paper, I like it, thanks for the pointer.  I'm curious
>why Peter thought what he thought, my guess would have been more like
>what the paper showed, but that was a "hand optimized assembly", maybe
>the compilers aren't that good?  I dunno, Peter, care to comment?

I agree that looks like an interesting paper - I've skimmed it and
will have to read it in details.  I was thinking back to when I was
using a mixture of SPARC and x86 at a previous job.  I didn't do any
careful analysis, more eyeballing various executables and gut feeling.
I no longer have access to that environment.  In view of that paper,
I'll withdraw my claim since it's not backed up by evidence.

-- 
Peter Jeremy

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Paul Winalski]

On 9/25/18, Tony Finch <dot@dotat.at> wrote:
> Peter Jeremy <peter@rulingia.com> wrote:
>
> This paper has a nice survey of instruction set densities, which very much
> disagrees with your statement:
>
> http://web.eece.maine.edu/~vweaver/papers/iccd09/iccd09_density.pdf

Thanks for the pointer to that paper.  Interesting reading.

There is an error in Table I (Summary of Investigated Architectures).
VAX is a pure little-endian architecture and can't operate on
big-endian data without byte swizzling.  Alpha, on the other hand, can
operate either big- or little-endian (selectable at system boot time).

The version of the Intel C compiler that they used--version 9--is a
little old in the tooth.  There have been several versions released
since then.

Interesting, and disappointing, that linking statically drags in the
entire C runtime.  Lo-level RTLs such as libc ought to be designed to
minimize dependencies between individual library routines (e.g., if I
call only strcmp(), strcmp.o and nothing else should participate in
the static link).

As the paper points out, compilers are usually designed to optimize
for execution speed rather than code size these days.

-Paul W.