HDTenEightyP/NetNews huggingface dataset:
From: John@boole.uucp (John Ahlstrom)
Subject: Re: Not using integers
Organization: Boole & Babbage, Inc.
Date: Mon, 14 Sep 1992 16:16:40 GMT

In <1265@taniwha.UUCP> paul@taniwha.UUCP (Paul Campbell) writes:

>In article <1992Sep8.182423.26063@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>>Does anybody here know of any microprocessors which did not use any integer
>>units or registers, but instead modified the floating point execution units
>>to inhibit the normalization pipe stage whenever an "integer" flag within
>>the instruction was set.

>The good old Burroughs 6700 (and family now called the A-series) had/has a 
>FP format for which a value with a 0 exponent looks like a 'normal' integer
>(they use a signed integer rather than a 2's complement one) - the hardware
>goes out of its way to keep a 0 exponent for values if it possibly can ...
>this means that there are no FP/INT instructions, there's only one ADD, SUB,
>MULT etc instructions

>	Paul
>-- 
>Paul Campbell    UUCP: ..!mtxinu!taniwha!paul     AppleLink: CAMPBELL.P

>       "Most American's day to day experience of 'Family Values' is found in
>	brightly colored fliers from such organisations as Target and K-Mart."

And Integer Store and Conditional Integer Store instructions when you had to 
finally store a value in an integer, or possibly integer variable.

John Ahlstrom
Boole & Babbage
"I cannot confirm or deny that these opinions are or are not
held by anyone else"
Xref: sparky comp.arch:9415 comp.lang.misc:3068
From: sog@craycos.com (Steve Gombosi)
Newsgroups: comp.arch,comp.lang.misc
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Date: 14 Sep 92 17:55:55 GMT
Organization: Cray Computer Corporation

In article <BuJnA9.JCA@mentor.cc.purdue.edu> hrubin@mentor.cc.purdue.edu (Rubin Herman) writes:
>
>This doubling is for the minis and micros, which are finding it possible to
>come closer to the speeds of fast mainframes.  The speed improvement from 
>the CRAY 1 to their latest machines is more in using multiple processors,
>but this will eventually run into physical limits.  The switching time has
>only tripled in a dozen years; there may be breakthroughs, but another 20
>doublings may very well reach basic physical limits in size, speed, and
>number of processors.

I believe you meant switching *speed*. A lot of the improvement from the Cray-1
to the original (2 processor) X-MP was due to speed-ups in the original
processor design. The faster clock was a minor improvement. Tripling
the number of vector<->memory paths, adding flexible chaining, reduction
of vector startup overhead, and allowing
chaining to memory operations helped a lot more. 

Throwing processors at a problem certainly helps, if the problem is 
sufficiently parallel to benefit and the overhead of multitasking it is 
sufficiently low. Everyone won't benefit - if your problem is only 90%
parallel, you can only speed it up by a factor of 10 whether you have
16 processors or 16 million - even *if* the multitasking overhead is zero.

Steve
From: john@theus.rain.com (John Theus)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: The Theus Group; Sherwood, OR
Date: Sun, 13 Sep 1992 08:08:43 GMT

In article <1992Sep13.033602.3708@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
>
>I've been computing for 17 years, and in all that time I don't think I've
>done characteristic roots more than a couple of times.  My sister has been
>word processing, spread-sheeting, etc. for six years, and I don't think she's
>ever done a characteristic root.  So, 23 years of computing, 2 roots. 
>
If you're using an ASCII display, then you may not be doing any roots. If you
ever do any serious graphics work, then its likely that square root is heavy
used. I used to be a system architect designing 3D graphics workstations for
applications like mechanical CAE/CAD. Root performance was always critical in
those systems, and our RISC processor vendors payed attention when we
complained about their lack of square root hardware.

Now, maybe you think the graphics market is unimportant to the RISC processor
vendors, but if that is so, why do several of the current generation parts
have graphics execution units?

>If you care to argue that computer architects are inadequately supporting an
>important (and profitable) application area, then do so.  Show us how design
>feature F costs C and gives benefit B.  Don't run around telling everyone that
>designs architectures or programming languages that they're stupid.  We're
>not.  We just have a more practical assessment of the value of those feature
>_to_the_market_as_a_whole_ than you appear to have.
>
Gee, I didn't know anyone in the CS department at Oregon State was designing
commercial processors with the marketing staff necessary to back up such a
statement.

John Theus     TheUs Group     +1 503 625 7387     john@theus.rain.com
Newsgroups: comp.arch
From: meissner@osf.org (Michael Meissner)
Subject: Re: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
Organization: Open Software Foundation
	<1992Sep13.033602.3708@CS.ORST.EDU>
	<1992Sep13.080843.7741@theus.rain.com>
Date: 14 Sep 92 15:09:29

In article <1992Sep13.080843.7741@theus.rain.com> john@theus.rain.com
(John Theus) writes:

| In article <1992Sep13.033602.3708@CS.ORST.EDU> crowl@jade.CS.ORST.EDU (Lawrence Crowl) writes:
| >
| >I've been computing for 17 years, and in all that time I don't think I've
| >done characteristic roots more than a couple of times.  My sister has been
| >word processing, spread-sheeting, etc. for six years, and I don't think she's
| >ever done a characteristic root.  So, 23 years of computing, 2 roots. 
| >
| If you're using an ASCII display, then you may not be doing any roots. If you
| ever do any serious graphics work, then its likely that square root is heavy
| used. I used to be a system architect designing 3D graphics workstations for
| applications like mechanical CAE/CAD. Root performance was always critical in
| those systems, and our RISC processor vendors payed attention when we
| complained about their lack of square root hardware.
| 
| Now, maybe you think the graphics market is unimportant to the RISC processor
| vendors, but if that is so, why do several of the current generation parts
| have graphics execution units?

I would expect that the typical company doing the Nth version of an
architecture (where N >= 2), will typically have various incentives,
requirements, etc. that the engineers use the N-m machine (typically
whatever the highend machine currently in production) to design the
chip.  I know this was true at Data General, and I believe I read
somewhere that MIPS used the R6000 to design the R4000.  Given this,
after one rev of the chip, you are one of your own customers.  Since
CAD apps use lots of square roots and graphics, it would make sense to
think about putting it in hardware.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.
Newsgroups: comp.arch,comp.parallel
From: barmar@think.com (Barry Margolin)
Subject: Re: sgi/sun shared memory machines question
Organization: Thinking Machines Corporation, Cambridge MA, USA
Distribution: usa
Date: 11 Sep 1992 19:58:48 GMT

In article <1992Sep11.121830.17069@hubcap.clemson.edu> zilla@nj.nec.com (John Lewis) writes:
>Someone told me that the SGI multiprocessor machines cannot run
>different unix processes on different processors; they can only
>run a single (but possibly parallelized) process at a given time.
>The reason was said to be that the machines do not implement
>any mechanism for simultaneous writes.
>
>Is this correct?  If so, how are simultaneous writes from
>different threads of a parallelized process prevented?

I don't know whether it's true or not.  But if it is, prevention of
simultaneous writes within a process can be prevented using a semaphore in
shared memory.  The write() routine would check this, and delay until the
semaphore is cleared.

>Is the new sun multiprocessor (4/690?) similar?

No, it's exactly opposite.  A process can only be on one processor at a
time, so each processor runs a different process.

Prevention of simultaneous writes is accomplished by only allowing one
processor to be in the kernel at a time.  Upcoming releases of the OS
removes this restriction, and uses locks around specific critical regions
of the kernel rather than the entire kernel.
-- 
Barry Margolin
System Manager, Thinking Machines Corp.

barmar@think.com          {uunet,harvard}!think!barmar

Newsgroups: comp.arch
From: jan@pallas.neuroinformatik.ruhr-uni-bochum.de (Jan Vorbrueggen)
Subject: Re: trapping speculative ops (LONG)
In-reply-to: schow@bqneh23.bnr.ca's message of Fri, 11 Sep 1992 14:37:05 GMT
Organization: Inst. f. Neuroinformatik, Ruhr-Universitaet Bochum, FRG
	<1992Sep11.143705.19214@bcars64a.bnr.ca>
Date: 12 Sep 92 15:23:38

In article <1992Sep11.143705.19214@bcars64a.bnr.ca> 
schow@bqneh23.bnr.ca (Stanley T.H. Chow) writes:

   Yes, the ideas are basically the same. IEEE method is inadequate for
   integer  which value would you like to use for NaI? :)

No problem  use MININT, if you're using two's complement, or 0,
if you're using one's complement. Gets rid of some obscure exceptions
in the process (eg, MININT).

Jan Vorbrueggen, Inst. f. Neuroinformatik, RuhrUniversitaet Bochum, FRG
Newsgroups: comp.arch
From: izahi@bsc.no (Raul Izahi Lopez Hernandez)
Subject: Re: Are 64 Int or FP registers useful?
Keywords: Chip Real State, Register Usage
Organization: Bergen Scientific Centre, Bergen, NORWAY
Date: Thu, 10 Sep 1992 07:26:30 GMT

In article <1992Sep8.140635.12078@infodev.cam.ac.uk> rf@cl.cam.ac.uk (Robin Fairbairns) writes:
>
>I can't offer a study, and I can't say anything about microprocessors.
>However... We used to have here a (mainframe) machine that offered
>user-mode programs free use of 93 registers (2 of which always read as
>zero, one of which was the program counter, and one of which was a
>register indexer - see that other thread...).
>
>The compilers for that machine _never_ made cogent use of this
>enourmous number of registers, except by way of the trick that one
>regularly used in assembler programs of loading "useful constants"
>into a set of registers at the start.  High-level language register
>dumps had a certain monotony about them...

   Could it be that the mainframe did not have multiple execution units
which could execute concurrently and therefore use, or at least benefit with
the use of, additional registers up to ~90 and beyond?


-- 
         -----> All opinions expressed here are my own, not IBM's <-----
Raul Izahi Lopez	Izahi Engineering
izahi@bsc.no		IBM Bergen Environmental Sciences and Solutions Centre
			Thormoehlensgate 55, 5008 Bergen, NORWAY (47-5)54-4653
Newsgroups: comp.arch
From: aki@akix.UUCP (Aki Atoji)
Subject: Re: Computer architects forced to change careers. NOT!
Organization: CxS Technologies
Date: Thu, 10 Sep 1992 21:19:43 GMT
	<1992Sep9.213319.7894@fasttech.uucp>

In article <1992Sep9.213319.7894@fasttech.uucp> zeke@fasttech.uucp (Bohdan Tashchuk) writes:

>>  The concept of reward for a job well done and punishment for an abject
>>  failure doesn't exist in many high-technology companies.
>> 
>>  The 432 should be studied in all engineering schools as an example of
>>  how NOT to design and implement a computer architecture.
>> 
>>  When screwups like this happen, a LOT of people get hurt in the
>>  resulting layoffs that endear the company to Wall Street.
>> 
>>  The concepts behind RISC have helped bring some sanity back into the field.

I think the above carries the confusion between technical achievement
and market acceptance/financial sucess.

Having worked with different CPU's of varying successes in market
place (i.e.  NS32K, x86, 29K and 960), I would have to say that the so
called 'technological superiority' of an architecture is often *not*
the only single important item for more design wins.

There really are numerous factors in getting design wins and thus more
market acceptance, such as pricing, availability, marketing, product
positioning in market place, tools (compilers, emulators, etc.), how
many freebies (i.e. compilers, eval board, eval chips) the
salescreature will give to you, etc. etc (free lunches would count
too, hint, hint :).

I'm not familiar with 432.  It just could have been a 'killer' chip.
On the other hand, according to one of the articles in comp.sys.intel
(I only browsed through it), 432 having been developed to exploit (or
'exercise') the HMOS process (including tools needed to do the chip
design), it may have served it's purpose very well, becoming the
spring board for the next generations of design.  Some designs can
purely be done for research.  Some designs can be done for research,
with some hopes for market success.  Some designs might have been done
for market acceptance, but the company might be pretending it was done
for research if it didn't sell well.  I somehow don't think 432 was
the last one.  

Some people still swear by 32K being the cleanest architecture ever.
It sure was easy to memorize the instruction set, but I don't think I
would have much employment opportunity for knowing this chip.

When 29K first came out, with it's MMU and three bus design, I'm sure
AMD's intent behind the design of the architecture was not to be one
of the most dominant RISC designs in the *embedded* market, which it is
now.  But then again, the number of 29K shipped is likely far less than
the 68K derivatives shipped (someone have actual numbers?).

However, these numbers are simply dwarfed by the number of 8051
derivatives shipped world wide.
-- 
---------------------------------------------------------------------------
Aki Atoji              Unix, X, Networking and Embedded Realtime Consulting
           aki@akix.uucp                      crash!akix!aki@trout.nosc.mil
---------------------------------------------------------------------------
From: davsmith@nic.cerf.net (David Smith)
Newsgroups: comp.arch
Subject: Re: SPARC Floating Point Query
Date: 16 Sep 92 03:06:02 GMT
Organization: CERFnet

In article <1992Sep9.135913.12073@gdr.bath.ac.uk> masjpf@gdr.bath.ac.uk (J P Fitch) writes:
>Can anyone throw any light on the following aspect of the SPARC?
>
>We have a trivial C program which calls double divide.  Compiled to
>assembler it creates what one might expect.  When we assemble the code
>and look with adb we find that the assembler has created an additional
>instruction, a fmovs, immediately after that fdivd.  We cannot find
>anything in the documentation we have been able to find to explain
>why, or what it is trying to avoid.  

The nearest I was ever able to figure out, that fmovs (basically an FP
no-op) is there to force the IU to take the FP exception that the fdivd
might have caused.  You see, in the SPARC architecture FP traps are
only handled by the IU when it issues an FP instruction to the FPU.
(SPARC Architecture manual, Rev A, page 53) Hence, the floating point
no-op to force the exception to be taken immediately so that you have
some clue about when the exception happens.  Unfortunately that little
kludge assumes that the exception will happen before the FP no-op is
issued.  This is true only if the FP queue is one deep or the FPU is
_very_ fast.  More recent SPARC implementations have FP queues deeper
than one.  I do not know how SUN is handling this with their compilers
for the Viking chip, for example.
-- 
David L. Smith
smithd@discos.com or davsmith@nic.cerf.net
From: firth@sei.cmu.edu (Robert Firth)
Newsgroups: comp.arch
Subject: Re: SPARC Floating Point Query
Date: 9 Sep 92 17:12:04 GMT
Organization: Software Engineering Institute

In article <1992Sep9.135913.12073@gdr.bath.ac.uk> masjpf@gdr.bath.ac.uk (J P Fitch) writes:
>Can anyone throw any light on the following aspect of the SPARC?

	fdivd	%f0,%f2,%f4		<<< Note well

**	fmovs	%f4,%f4		** added by Assembler

	fdtoi	%f4,%f5
	st	%f5,[%sp+LP12]

[a heap of monstrously bloated and stupendously bad generated code
 deleted, since I don't want to see it again and I'm sure you don't]

I suspect the answer is to be found in the Sparc Architecture manual,
section C.6, which deals with the issues of floating point execution.
The processor can execute one or more Fp ops concurrently, which raises
the issue of when this is safe.  The spec I have seems to be wrong, ie
it does not accurately describe the behaviour of the machine, but what
*seems* to be the case [Warning - I may be wrong!] is that

	if an FP op is executing, that uses a register %fx, and
	a new FP instruction is fetched, that makes a conflicting
	use of %fx, then the new instruction will be delayed until
	the earlier completes, IF the new instrcution is a load,
	store, or move (plus some special cases not germane).

Thus, these are safe:

	fadd %f0,%f2,%f2
	ld   [src],%f0		; will delay until fadd no longer needs %f0

	fadd %f0,%f2,%f4
	st   %f4,[dest]		; will delay until fadd writes to %f4

But this is unsafe:

	fdivd %f0,%f2,%f4
	fdtoi %f4,%f5

since the second instruction is allowed to start before the first completes.

The assembler seems to be solving this problem by inserting a dummy move:

	fdivd %f0,%f2,%f4
	fmovs %f4,%f4

to force completion of the divide.  Whether this is necessary depends on
how many instructions your FPU can execute concurrenyly - if that number
is one, you can get away without the fmov.

Sigh.  sunt lacrimae rerum.
Newsgroups: comp.arch
From: sgolson@trilobyte.com (Steve Golson)
Subject: Re: HP-9100 (was HP-97 Calculator)
Organization: Trilobyte Systems
Date: Thu, 3 Sep 1992 14:54:32 GMT

In article <5647@armltd.uucp> abaum@armltd.uucp (Allen Baum) writes:
>jones@pyrite.cs.uiowa.edu (Douglas W. Jones,201H MLH,3193350740,3193382879) writes:
>
>>The diode matrix contains low level microcode [for] a digit serial processor
>>The middle layer microcode is stored in a braided wire memory;
>
>I thought that the microcode was stored in an inductively coupled ROM, consisting of
>a 14 layer pc board, where the inner layer traces defined the bits. The Russians
>copied this calculator, which meant they had to peel back every layer of the PC board
>to do it.

Quoting from _Hewlett-Packard Journal_, v20n1, September 1968 (reprinted in
_Computer Structures: Readings and Examples_ by Bell and Newell, 1971, also
in _Computer Structures: Principles and Examples_ by Siewiorek, Bell and
Newell, 1982):

   The control logic uses a wire braid toroidal core read only memory
   containing 64 29-bit words. ...

   The 32,768 bit read only program memory consists of 512 64-bit words.
   These words contain all of the operating subroutines, stored constants,
   character encoders, and CRT modulating patterns.  The 512 words are
   contained in a 16 layer printer-circuit [sic] board having drive and
   sense lines orthogonally located. ... When the program ROM is activated,
   signals (micro-instructions) corresponding to the bit pattern in the word
   are sent to the hard wired logic gates...

   All of the hard wired logic gates are synthesized on the instruction
   logic board using time-proven diode-resistor logic.

There is also a 2208 (6 x 16 x 23) bit read/write core memory for storing
user programs and data.

>The digit serial processor was extremely primitive- it couldn't add, just increment or
>decrement a digit. Addition/subtraction was programmed from that, and multiplication,
>division, exps/trigs/etc. programmed from those.

Not exactly. The 9100A has a digit-serial, bit-parallel ALU. It can add, but
only one BCD digit at a time. All calculations are floating point, and are
performed digit by digit. This technique is common to many calculators.

>The logic family is interesting. The boards are masses of diodes, (& resistors) packed
>about as tightly as you could, with a few transistors here and there. It was discrete
>DTL logic, with additional feature that one of the inputs was the power supply, and
>it was wired up so that the input least likely to be turned on was the one connected
>to the power supply, to conserve power.

A total of 350 logic gates, containing 750 diodes and 325 resistors. My, how
far we've come...

>Allen J. Baum		Apple Computer		baum@apple.com, abaum@armltd.co.uk

Steve Golson -- Trilobyte Systems -- Carlisle MA -- sgolson@trilobyte.com
"As the people here grow colder, I turn to my computer..." -- Kate Bush
From: abaum@armltd.uucp (Allen Baum)
Newsgroups: comp.arch
Subject: Re: Not using integers
Date: 10 Sep 92 13:23:13 GMT
Organization: Advanced RISC Machines Ltd

In article <1992Sep8.182423.26063@athena.mit.edu> solman@athena.mit.edu (Jason W Solinsky) writes:
>Does anybody here know of any microprocessors which did not use any integer
>units or registers, but instead modified the floating point execution units
>to inhibit the normalization pipe stage whenever an "integer" flag within
>the instruction was set.

I don't believe any microprocessors have done this; there have n't been many micros
that have had floating point, period.

But, I seem to recall the Burroughs 5000 series mainframes did something like that.
Integer was just a special case of FP.-- 

----------------
Allen J. Baum		Apple Computer		baum@apple.com, abaum@armltd.co.uk
From: thorinn@diku.dk (Lars Henrik Mathiesen)
Newsgroups: comp.arch
Subject: Re: trapping speculative ops (LONG)
Date: 10 Sep 92 18:03:03 GMT
Organization: Department of Computer Science, U of Copenhagen

anton@mips.complang.tuwien.ac.at (Anton Martin Ertl) writes:
>thorinn@diku.dk (Lars Henrik Mathiesen) writes:
>|> [...] currently, compilers have no reason to write the same
>|> register twice without intervening reads, [...]

>This is true in straight-line code, but generally a write to a
>register is only redundant if *all* possible execution paths that
>execute it write to the register another time before reading it.

True --- but I would guess that most such cases have a fair bit of
code between the writes, and so the write-write stall is too rare to
concern the hardware architects. But in an exception-bit architecture,
write-after-write could be almost a paradigm --- speculative
operations can be issued with the ``true'' destination register, and
if they turn out to be ``wrong,'' some other valued is loaded into the
register. Imaginary code for "if (p) p = p->next;":

	; p is in R1
	LD	0(R1),R2	; start load
	ADD	R1,R0,R0	; test p
	ADD,EQ	R1,R0,R2	; override load if p == 0
	; p is now in R2!

>|> [...] trap bits on source operands should not [...] trap, but
>|> should propagate to the result instead.

>[...] how do we know which instruction caused the exception? [...] We
>check the trap bit of the original trap-noting instruction. This
>means of course that the compiler has to keep the trap bit alive,
>which restricts register allocation, if the trap bit is associated
>with the destination register.

I did not want to clutter up my previous post, but that is exactly
what I had in mind: If the equivalent of exact traps is wanted, the
compiler has to keep every speculatively calculated intermediary alive
until the exception can be taken. This means that the compiler needs/
can utilize more registers than usual, but we're talking about a new
architecture anyway, and I get the impression that registers are cheap
nowadays, or at least not very expensive.

Lars Mathiesen (U of Copenhagen CS Dep) <thorinn@diku.dk> (Humour NOT marked)
Xref: sparky comp.arch:9396 comp.lang.misc:3060