Re: [TUHS] SPARC is CRAPS spelled backwards.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Noel Chiappa]

    > From: Arthur Krewat

    > Also, granted, to this day you can still use only 8-bits of a register:

Yeah, but that's not totally useless; lots of byte-organized data out there in
the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
networking protocols (checksums, ports, etc - although the checksums you
_compute_ using bigger chunks).

(Not a defense of the x86 instruction set, mind!)

     Noel

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Theodore Y. Ts'o]

On Tue, Sep 25, 2018 at 08:12:12AM -0400, Noel Chiappa wrote:
>     > From: Arthur Krewat
> 
>     > Also, granted, to this day you can still use only 8-bits of a register:
> 
> Yeah, but that's not totally useless; lots of byte-organized data out there in
> the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
> networking protocols (checksums, ports, etc - although the checksums you
> _compute_ using bigger chunks).

Windows and Microsoft Office still uses UTF-16....

					- Ted

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Derek Fawcus]

On Tue, Sep 25, 2018 at 10:49:08AM -0400, Theodore Y. Ts'o wrote:
> 
> Windows and Microsoft Office still uses UTF-16....

As do Mac's, and probably iOS; the Foundation framework uses it for NSString.

DF

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Arthur Krewat]

On 9/25/2018 8:12 AM, Noel Chiappa wrote:
>      > From: Arthur Krewat
>
>      > Also, granted, to this day you can still use only 8-bits of a register:
>
> Yeah, but that's not totally useless; lots of byte-organized data out there in
> the world, e.g. ASCII strings. 16-bit data, less so, although there is some in
> networking protocols (checksums, ports, etc - although the checksums you
> _compute_ using bigger chunks).
>
> (Not a defense of the x86 instruction set, mind!)
>
>       Noel
>
>
Oh, I like 8-bit operations... I use them a lot. Coming from MACRO-10 on 
a 36-bit PDP-10 I used in high school, the move to microcomputers was 
challenging in some ways, but much easier in others. Especially 7 or 8 
bit operations.

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Nelson H. F. Beebe]

Noel Chiappa <jnc@mercury.lcs.mit.edu> comments on the use of "home
directory" on Thu, 27 Sep 2018 19:14:19 -0400 (EDT):

>> I _did_ find "home directory" in the ITS documentation; the oldest doc file I
>> found it in was dated 5/25/79. If ITS was the source, not sure how it spread -
>> maybe via EMACS?

I looked in my own TECO code (> 12K lines), and found "home directory"
in two files with internal date headers from 1983.

I scanned my archive of TOPS-20 emacs source code and found these
uses:

	% grep -i 'home dire' *
	babyl.info:operating system; this file resides in the user's "home directory" and
	conv.info:stands for the user's home directory.  If neither file exists, the
	emacs.info:Home Directory  Your home directory is the one on which your mail and
	emacs.info:                may be the same as your home directory's name.
	emacs.mss:@Index{Home Directory}@Index{User Name}
	emacs.mss:it should be called @ITS{<home directory>;<user name> EVARS instead of EMACS.}
	emacs.mss:@Index{Home Directory}
	emacs.mss:EMACS into the file @ITS[<home directory>;TS ESAVE]@Twenex[ESAVE.EXE].
	Binary file mkdump.info matches
	teco.archiv:*) FS U HSNAMEnd FS U MAILllow you to get a user's home directory
	teco.archiv:* FS HSNAME$ is the user's home directory, as a numeric sixbit word.
	teco.archiv:On old versions of ITS that don't have home directories, it is the
	teco.archiv:same as FS MSNAME$.  The home directory is (presumably) where such things
	teco.archiv: B) People whose home directory is a shared directory
	tecord.info:    If you @EJ a file TS FOO on your home directory, then FOO^K
	tecord.info:FS HSNAME   s the user's home directory.  The home directory
	tecord.ref:FS HSNAME    user's home directory
	tecord.ref:FS U HSNAME  used to determine a user's home directory

Here are the file dates:

	% grep -l -i 'home dire' * | xargs ls -log
	-rw-r--r-- 1  51376 Jun  5  1981 babyl.info
	-rw-r--r-- 1  81689 Oct 16  1981 conv.info
	-rw-r--r-- 1 466772 Dec 28  1981 emacs.info
	-rw-r--r-- 1 412673 Oct 16  1981 emacs.mss
	-rw-r--r-- 1  12570 May 24  1982 mkdump.info
	-rw-r--r-- 1 121865 Oct 16  1981 teco.archiv
	-rw-r--r-- 1 225207 Oct 16  1981 tecord.info
	-rw-r--r-- 1  16407 Dec 28  1981 tecord.ref

In another directory named emacs-162, there were 18 files containing
"home directory"; the oldest is dated 6-Mar-1980.

However, when I dug into teco.archiv, I found that the match occurred
in a change log block that begins

	TECO 699:
	RMS 10/14/77  Many changes
	...
	ITS only:

Thus, 14-Oct-1977 is the earliest date that I can find for "home
directory", credited to Richard Stallman.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Norman Wilson]

NUXIi  s artdamera kfoB le laLobarotirse

(A few of you are expected to understand this.)

Norman Wilson
Toronto ON

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Nelson H. F. Beebe]

As a followup to discussions on this thread about hardware
architectures, some of you may be interested in this new letter
published today:

	Letters to the editor: Hennessy and Patterson on the roots of RISC
	Comm. ACM 61(10) 6 (2018)
	https://doi.org/10.1145/3273019
	http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf

The short two-paragraph letter is from Fred Brooks, noted computer
architect, author, and computer scientist.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu  -
- 155 S 1400 E RM 233                       beebe@acm.org  beebe@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Nemo]

On 27/09/2018, Nelson H. F. Beebe <beebe@math.utah.edu> wrote:
> As a followup to discussions on this thread about hardware
> architectures, some of you may be interested in this new letter
> published today:
>
> 	Letters to the editor: Hennessy and Patterson on the roots of RISC
> 	Comm. ACM 61(10) 6 (2018)
> 	https://doi.org/10.1145/3273019
> 	http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf

Also of interest may be the video "SPARC at 25"
(https://www.youtube.com/watch?v=w3ukXhEaYGI ), wherein Patterson,
Joy, and others discuss SPARC.  (Joy's comment on register windows is
interesting and matches Brooks' remark.)

N.

>
> The short two-paragraph letter is from Fred Brooks, noted computer
> architect, author, and computer scientist.
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>  -
> - University of Utah                    FAX: +1 801 581 4148
>  -
> - Department of Mathematics, 110 LCB    Internet e-mail: beebe@math.utah.edu
>  -
> - 155 S 1400 E RM 233                       beebe@acm.org
> beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
> -------------------------------------------------------------------------------
>

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Dan Cross]

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

On Thu, Sep 27, 2018 at 3:16 PM Nelson H. F. Beebe <beebe@math.utah.edu>
wrote:

> As a followup to discussions on this thread about hardware
> architectures, some of you may be interested in this new letter
> published today:
>
>         Letters to the editor: Hennessy and Patterson on the roots of RISC
>         Comm. ACM 61(10) 6 (2018)
>         https://doi.org/10.1145/3273019
>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf


Aside: This is taking an inordinately long time to download from the ACM.
It must be "the TUHS effect."

        - Dan C.


> The short two-paragraph letter is from Fred Brooks, noted computer
> architect, author, and computer scientist.
>
>
> -------------------------------------------------------------------------------
> - Nelson H. F. Beebe                    Tel: +1 801 581 5254
>     -
> - University of Utah                    FAX: +1 801 581 4148
>     -
> - Department of Mathematics, 110 LCB    Internet e-mail:
> beebe@math.utah.edu  -
> - 155 S 1400 E RM 233                       beebe@acm.org
> beebe@computer.org -
> - Salt Lake City, UT 84112-0090, USA    URL:
> http://www.math.utah.edu/~beebe/ -
>
> -------------------------------------------------------------------------------
>

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

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Cág]

Dan Cross wrote:

>>         Letters to the editor: Hennessy and Patterson on the roots of RISC
>>         Comm. ACM 61(10) 6 (2018)
>>         https://doi.org/10.1145/3273019
>>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf
> 
> Aside: This is taking an inordinately long time to download from the ACM.
> It must be "the TUHS effect."

For me it doesn't even work:
"An error occurred while processing your request."

--
caóc

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Henry Bent]

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

On Thu, 27 Sep 2018 at 16:52, Cág <ca6c@bitmessage.ch> wrote:

> Dan Cross wrote:
>
> >>         Letters to the editor: Hennessy and Patterson on the roots of
> RISC
> >>         Comm. ACM 61(10) 6 (2018)
> >>         https://doi.org/10.1145/3273019
> >>         http://delivery.acm.org/10.1145/3280000/3273019/p6-friedman.pdf
> >
> > Aside: This is taking an inordinately long time to download from the ACM.
> > It must be "the TUHS effect."
>
> For me it doesn't even work:
> "An error occurred while processing your request."
>

The direct PDF link that Nelson posted doesn't work, but if you go to the
first link and select "PDF" it should work.

-Henry

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

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Cág]

Henry Bent wrote:

> The direct PDF link that Nelson posted doesn't work, but if you go to the
> first link and select "PDF" it should work.

Thanks! Is it intended?

--
caóc

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Paul Ruizendaal]

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

The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC.

Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based  on Sys III. This was marketed by IBM.

Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0.

These versions are a hole in the TUHS archive (unless they are in the confidential archive). It would be wonderful if MS would open up pre-1984 Xenix on the occasion of Unix 50th. These builds would well illustrate the broad Unix portability, which was unique at the time.

Paul

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Arrigo Triulzi]

On 27 Sep 2018, at 09:35, Paul Ruizendaal <pnr@planet.nl> wrote:
>> 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?
> 
> The first version of Venix-86 ran on the PC/XT, almost a 5150, in May 83. It was V7 based. I think it was the first Unix on a PC.
> 
> Heinz Lycklama (who did Unix LSX and MX at Bell labs in the 70’s) did PC/IX about a year later, based  on Sys III. This was marketed by IBM.
> 
> Based on the early Xenix porting chart here http://seefigure1.com/2014/04/15/xenixtime.html , a PC/XT version of Xenix appeared around the same time as PC/IX. However, if the chart is correct there may have been Xenix versions for other 8086-based machines a year before that. Note that in this chart the “Xenix 2.0” and “Xenix 3.0” labels refer to MS internal versions, i.e. these numbers are not to be confused with the marketing labels IBM PC Xenix 2.0 and 3.0.

I am almost certain of the existence of a Unix variant for the Olivetti M24 which was an 8086-equipped PC (The M24 was rebranded as an AT&T 6300 if memory serves me correctly). It might have been Xenix or Venix but I honestly cannot remember it as I certainly recall Xenix floppies & manuals making the rounds later on 286s in Italy but I only faintly recall the M24 Unix.

Arrigo

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Noel Chiappa]

    > From: Tony Finch

    > This paper has a nice survey of instruction set densities

And the winner is.... the PDP-11!

I'm not too surprised by this; back in the days of core memory (and limited,
at that - the first PDP-11's came standard with ... 8KB of memory :-), having
the denset possible code had real savings.

    Noel

Re: [TUHS] SPARC is CRAPS spelled backwards.

[Noel Chiappa]

    > From: Paul Winalski

    > In general, a CISC instruction set encoding can express the same
    > algorithm more compactly than a RISC instruction set.

I have often pointed to memory bandwidth as one of the key factors in the
evolution of CISC and RISC. When it was low, compared to CPU speeds (most of
the core era), CISC made sense. When it increased (with DRAM), RISC made more
sense, because it allowed CPUs to run faster (via simpler instructions).

Caching made the picture a little more complex; and today, with the incredible
mismatch between memory speeds and CPU speeds, caching dominates, whether you
have RISC or CISC.

     Noel

[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 --]

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.