Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch > #1642 > unrolled thread

Re: Why is complex lea slow?

Back to article view | Back to comp.arch

Contents

  Re: Why is complex lea slow? "Paul A. Clayton" <paaronclayton@gmail.com> - 2011-05-17 12:58 -0700
    Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-18 09:40 +0200
      Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-18 06:25 -0700
        Re: Why is complex lea slow? "Andy \"Krazy\" Glew" <andy@SPAM.comp-arch.net> - 2011-05-18 06:39 -0700
        Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-18 20:49 +0200
        Re: Why is complex lea slow? Andrew Reilly <areilly---@bigpond.net.au> - 2011-05-19 00:11 +0000
      Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-24 13:44 -0700
        Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-25 08:43 +0200
          Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-25 08:31 -0700
        Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-25 14:53 +0000
          Re: Why is complex lea slow? MitchAlsup <MitchAlsup@aol.com> - 2011-05-25 08:31 -0700
            Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-26 19:45 +0000
              Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:01 +0000
                Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 20:29 +0100
                  Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:14 +0000
                    Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 21:04 +0100
                      Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:55 +0000
                        Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-26 20:57 +0000
                        Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-26 21:30 +0100
                        Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-26 22:57 +0100
                          Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 07:42 +0200
                            Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:11 +0000
                              Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 07:18 +0100
                                Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:33 +0000
                                Re: Why is complex lea slow? Michael S <already5chosen@yahoo.com> - 2011-05-27 03:24 -0700
                                  Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 22:24 +0100
                                    Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-28 13:51 +0200
                                  Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:42 -0700
                                Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:40 -0700
                              Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 08:55 +0200
                                Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 07:42 +0000
                                  Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 09:24 +0100
                                    Re: Why is complex lea slow? nmm1@cam.ac.uk - 2011-05-27 08:55 +0100
                                      Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 10:20 +0100
                                    Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 08:53 +0000
                                      Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-27 10:23 +0100
                                        Re: Why is complex lea slow? kenney@cix.compulink.co.uk - 2011-05-27 23:47 -0500
                                    Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:44 -0700
                                      Re: Why is complex lea slow? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-05-28 02:12 +0100
                                        Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-28 02:57 +0000
                                        Re: Why is complex lea slow? Tom Gardner <spamjunk@blueyonder.co.uk> - 2011-05-28 09:27 +0100
                                          Algol hardware representations, was: Why is complex lea slow? Bill Findlay <yaldnif.w@blueyonder.co.uk> - 2011-05-28 15:26 +0100
                                        Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-28 08:57 -0700
                              Re: Why is complex lea slow? Chris Gray <cg@GraySage.com> - 2011-05-27 14:14 -0600
                        Re: Why is complex lea slow? timcaffrey@aol.com (Tim McCaffrey) - 2011-05-26 23:26 +0000
                      Re: Why is complex lea slow? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-26 21:41 -0600
                Re: Why is complex lea slow? Terje Mathisen <"terje.mathisen at tmsw.no"> - 2011-05-27 07:37 +0200
                  Re: Why is complex lea slow? kym@kymhorsell.com - 2011-05-27 06:16 +0000
                  Re: Why is complex lea slow? Quadibloc <jsavard@ecn.ab.ca> - 2011-05-27 17:52 -0700
    Re: Why is complex lea slow? Piotr Wyderski <peter.pan@neverland.mil> - 2011-05-19 17:13 +0200

Page 1 of 3  [1] 2 3  Next page →

#1642 — Re: Why is complex lea slow?

On Tuesday, May 17, 2011 1:01:01 AM UTC-4, MitchAlsup wrote:
> On May 16, 1:02 pm, "Paul A. Clayton" 
[snip]
> A "good" 64-bit adder/ALU will have 11-gates of delay
> Making that adder do 3-input adds is 2 more gate dalays (13 total).

So cracking three-operand forms of LEA could allow a 10+% 
increase in clock frequency (if the ALU was the main 
cycle time limiter); that certainly seems to make 
penalizing such operations a reasonable choice.

[snip]
> It is my opinion that you are chasing timing ghosts, and that you will
> make more forward progress, faster, by consentrating on the hard (i.e.
> late) stuff rather than trying to eak out a gat delay on the easy
> stuff.

Such might not be a timing ghost (speeding up one aspect 
merely exposing another latency-inducing factor or--worse--
introducing a new latency-inducing factor?) even if it 
would be more profitable to work on other optimizations.
I do strongly suspect that there are greater optimization 
opportunities available (even Intel does not have 
infinite design resources).


In the context of LEA, the shifts are always constant and 
I was under the impression that variable shifts are 
generally less common.  I also suggested that early 
forwarding of the LSbits could be used to warm up the 
muxes for variable shifts.  I was mainly thinking in 
terms of shift-and-add (bringing the time closer to a 
simple addition), but there might be some advantage to 
being able to relax the timing on the shifter for 
separate operations (area or power tradeoffs?).

[toc] | [next] | [standalone]

#1647

Paul A. Clayton wrote:
> In the context of LEA, the shifts are always constant and
> I was under the impression that variable shifts are
> generally less common.

Chicken & Egg?

Variable shifts have tended to be slower on many (micro-)architectures, 
making programmers (and compiler writers) less likely to use them.

I.e. I have written lots of code, particularly anything that has to do 
with bit banging, where fast variable shifts would have allowed me to 
simplify the code and/or employ bit-level packing instead of using a 
byte per flag.

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

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

#1663

On 5/18/2011 12:40 AM, Terje Mathisen wrote:
> Paul A. Clayton wrote:
>> In the context of LEA, the shifts are always constant and
>> I was under the impression that variable shifts are
>> generally less common.
>
> Chicken & Egg?
>
> Variable shifts have tended to be slower on many (micro-)architectures,
> making programmers (and compiler writers) less likely to use them.
>
> I.e. I have written lots of code, particularly anything that has to do
> with bit banging, where fast variable shifts would have allowed me to
> simplify the code and/or employ bit-level packing instead of using a
> byte per flag.
>
> Terje

The x86 OOO/P6 family slowness for variable shifts is largely due to the 
fact that a variable shift by zero was defined be a NOP.  On a 2-input 
OOO machine, this necessitated a third input for the old flags, and a 
second uop:

       tmp := concat( value_to_be_shifted, old_flags )
       dest,new_flags := shift( tmp, shift_count )

or (with lower latency for the shift, and a widget uop to handle to flag 
selection)

       dest,tmp_flags := shift( value_to_be_shifted, shift_count )
       final_flags := select_shift_flags( tmp_flags, old_flags)


If the instruction had been defined without this 0-NOP flag business, 
e.g. if you set a flag combination on zero rather than inheriting one, 
it would have been faster.

Now that 3-input datapaths are common for multiply-add, this could be 
undone.  Perhaps it has already been?

---

Apart from this, why are dynamic shifts slow?   What machines make them 
slow?

A dynamic shift is always going to be more expensive than a shift by 1 
or 2 bits.  At least, you can probably build 4 shift by 1s, but only 1 
dynamic full width shifter, on a typical datapath.  But not necessarily 
more expensive  than a shift by a large constant, unless tyhe sort of 
optimization Paul was talking about is done.  Which has not been the 
case in my experieence.

But, you are right: dynamic shifts are often penalized.

E.g. on Gould we  did not have them:  we had to resort to the moral 
equivalent of self-modifying code, generating the shift by constant in a 
register and then using the execute register instruction.

This sounds like an essay for the comp-arch.net wiki.

What machines make dynamic shifts slower than, say, a shift by 29?

Why?

Is it fundamental, or is it an accident of the instruction set, as it 
was for x86 and Gould?

What would an instruction set definition of dynamic shift look like that 
did NOT causse such implementation artifacts look like?

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

#1665

> This sounds like an essay for the comp-arch.net wiki.

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

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

#1671

Andy "Krazy" Glew wrote:
> On 5/18/2011 12:40 AM, Terje Mathisen wrote:
>> I.e. I have written lots of code, particularly anything that has to do
>> with bit banging, where fast variable shifts would have allowed me to
>> simplify the code and/or employ bit-level packing instead of using a
>> byte per flag.
>>
>> Terje
>
> The x86 OOO/P6 family slowness for variable shifts is largely due to the
> fact that a variable shift by zero was defined be a NOP. On a 2-input
> OOO machine, this necessitated a third input for the old flags, and a
> second uop:
[snip]
> If the instruction had been defined without this 0-NOP flag business,
> e.g. if you set a flag combination on zero rather than inheriting one,
> it would have been faster.

Since the definition was (modulo bugs) however the 808x did it, a 
microcoded variable shift where no shift == NOP probably made sense at 
the time. :-(

> E.g. on Gould we did not have them: we had to resort to the moral
> equivalent of self-modifying code, generating the shift by constant in a
> register and then using the execute register instruction.

Having an execute instruction, like the IBM 360/370, makes 
self-modifying code both simple and relatively clean.

I.e. it becomes very obvious where you are doing this stuff, and you can 
leave your code segments read-only.

You could of course have done the same thing with computed branch addresses:

Either a completely unrolled version:

   and cx,31	; 0 to 31 shift count
   mov bx, offset shift_end
   sub bx,cx
   sub bx,cx
   sub bx,cx
   jmp bx
shift_start:
   rept 31
     shr ax,1	;; A 3-byte opcode
   endm
shift_end:

or a binary set of fixed-size shifts:

   test cl,16
    jz skip16
   shr ax,16
skip16:
   test cl,8
    jz skip8
   shr ax,8
skip8:
...
etc.
   test cl,1
    jz skip1
   shr ax,1
skip1:

Terje

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

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

#1674

On Wed, 18 May 2011 06:25:30 -0700, Andy \"Krazy\" Glew wrote:

> What machines make dynamic shifts slower than, say, a shift by 29?
> 
> Why?

Some ARM versions are one cycle slower for dynamic than immediate 
shifts.  I can't say why: always assumed it was a pipeline issue, 
register read vs instruction constant...

[Note that shifting isn't a special instruction in the traditional ARM 
instruction set, it's something that you can do to the second argument of 
any ALU operation.]

Cheers,

-- 
Andrew

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

#1807

On May 18, 2:40 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
> Variable shifts have tended to be slower on many (micro-)architectures,
> making programmers (and compiler writers) less likely to use them.
>
> I.e. I have written lots of code, particularly anything that has to do
> with bit banging, where fast variable shifts would have allowed me to
> simplify the code and/or employ bit-level packing instead of using a
> byte per flag.

Mc88K architecture has bit manipulation instructions where the
degenerate versions masquarade as shift instructions. These were
available in both immediate and 3-register forms, so one could write
dynamic bit-banging code in (non-portable) 'C'. We used these directly
in the compiler to implement bit-fields in 'C' and shift instructions.
The 'C' programmer could access the bit manipulation capabilities by
using shift 'counts' with bits above those use for the shift control

This set of instructions were very powerful and one of the few major
mistakes I made in the 88K. Had I separated the two-5-bit fields that
specified the shift count and the field length portability to a 64-bit
version would have been much easier. Since the constant field was 16-
bits in size there were plenty of spare space in the immediate to
allow some separation of the two fields.

The 88100 was significantly faster interpreting 68020 Macintosh code
than was the <first shipping> PPC Macintosh.

Mitch

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

#1814

MitchAlsup wrote:
> On May 18, 2:40 am, Terje Mathisen<"terje.mathisen at tmsw.no">
> wrote:
>> Variable shifts have tended to be slower on many (micro-)architectures,
>> making programmers (and compiler writers) less likely to use them.
>>
>> I.e. I have written lots of code, particularly anything that has to do
>> with bit banging, where fast variable shifts would have allowed me to
>> simplify the code and/or employ bit-level packing instead of using a
>> byte per flag.
>
> Mc88K architecture has bit manipulation instructions where the
> degenerate versions masquarade as shift instructions. These were
> available in both immediate and 3-register forms, so one could write
> dynamic bit-banging code in (non-portable) 'C'. We used these directly
> in the compiler to implement bit-fields in 'C' and shift instructions.
> The 'C' programmer could access the bit manipulation capabilities by
> using shift 'counts' with bits above those use for the shift control

OK, so instead of masking the shift count you used the top bits to 
specify the size of bitfields?

Leaving those bits empty presumably had to result in a regular shift, 
without any extra masking, so was this a special case or did you define 
it in such a way that a zero mask field resulted in no masking being 
performed?
>
> This set of instructions were very powerful and one of the few major
> mistakes I made in the 88K. Had I separated the two-5-bit fields that
> specified the shift count and the field length portability to a 64-bit
> version would have been much easier. Since the constant field was 16-
> bits in size there were plenty of spare space in the immediate to
> allow some separation of the two fields.

Ouch!

There are some good reasons (as we have discussed previously) for 
allowing shift counts at least as large as the register size, and 
preferably up to 2N-1, i.e. 63 bits for a 32-bit register/127 bits for 
64-bit code. (The actual result should of course be the same as if the 
count was clamped at N, i.e. any left shift of N or more bits results in 
zero.)

In your case it seems like you could have allowed up to 8 bits for each 
of the fields, right?
>
> The 88100 was significantly faster interpreting 68020 Macintosh code
> than was the<first shipping>  PPC Macintosh.

<BG>

Terje

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

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

#1822

On May 25, 1:43 am, Terje Mathisen <"terje.mathisen at tmsw.no">
wrote:
> In your case it seems like you could have allowed up to 8 bits for each
> of the fields, right?

Coulda, woulda, shoulda, realized about 1 year too late........

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

#1820

In article 
<26f7a23a-3323-42bf-a3b8-c24bdd7cb7c9@k15g2000pri.googlegroups.com>, 
MitchAlsup@aol.com says...
>
>On May 18, 2:40=A0am, Terje Mathisen <"terje.mathisen at tmsw.no">
>wrote:
>> Variable shifts have tended to be slower on many (micro-)architectures,
>> making programmers (and compiler writers) less likely to use them.
>>
>> I.e. I have written lots of code, particularly anything that has to do
>> with bit banging, where fast variable shifts would have allowed me to
>> simplify the code and/or employ bit-level packing instead of using a
>> byte per flag.
>
>Mc88K architecture has bit manipulation instructions where the
>degenerate versions masquarade as shift instructions. These were
>available in both immediate and 3-register forms, so one could write
>dynamic bit-banging code in (non-portable) 'C'. We used these directly
>in the compiler to implement bit-fields in 'C' and shift instructions.
>The 'C' programmer could access the bit manipulation capabilities by
>using shift 'counts' with bits above those use for the shift control
>
>This set of instructions were very powerful and one of the few major
>mistakes I made in the 88K. Had I separated the two-5-bit fields that
>specified the shift count and the field length portability to a 64-bit
>version would have been much easier. Since the constant field was 16-
>bits in size there were plenty of spare space in the immediate to
>allow some separation of the two fields.
>
>The 88100 was significantly faster interpreting 68020 Macintosh code
>than was the <first shipping> PPC Macintosh.
>
>Mitch
These were bit field extract & insert instructions?  That is what the Unisys 
Clearpath MCP systems have (since the 60s), and NEC added them to the x86 
instruction set with the V20/V30.

I want Intel to add a multi-bit field extract instruction, but its a hard 
sell.

	- Tim

	- Tim

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

#1823

On May 25, 9:53 am, timcaff...@aol.com (Tim McCaffrey) wrote:
> These were bit field extract & insert instructions?  That is what the Unisys
> Clearpath MCP systems have (since the 60s), and NEC added them to the x86
> instruction set with the V20/V30.

Extract unSigned
Extract Signed
Rotate Field
Clear Field (zeros)
Set Field (ones)
Make Field

To insert a field into a container, one clears the field from the
container, makes the field (aligns it where it is supposed to be in
the container) then ORs them together. The bit field instructions do
all the field level masking, but doing an insert in a RISC
architecture did not work (4-register instruction). We did teach the C
compiler that if it needed to clear more than one field in a
container, it could do so in a single CLR instruction.

Extract instructions were the left shift varietals, Make was the right
shift varietal.

These instructions were added to the AMD version of x86 about 4 years
ago with the exception that one can directly insert (single
instruction) in the AMD machines. Don't know about the Intel versions.

What was the name of the architecture before Unisys renamed it to
ClearPath?

Mitch

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

#1858

In article <732e25ea-5ce7-4f03-ae89-42313ed149fd@z7g2000prh.googlegroups.com>, 
MitchAlsup@aol.com says...
>
>On May 25, 9:53=A0am, timcaff...@aol.com (Tim McCaffrey) wrote:
>> These were bit field extract & insert instructions? =A0That is what the U=
>nisys
>> Clearpath MCP systems have (since the 60s), and NEC added them to the x86
>> instruction set with the V20/V30.
>
>Extract unSigned
>Extract Signed
>Rotate Field
>Clear Field (zeros)
>Set Field (ones)
>Make Field
>
>To insert a field into a container, one clears the field from the
>container, makes the field (aligns it where it is supposed to be in
>the container) then ORs them together. The bit field instructions do
>all the field level masking, but doing an insert in a RISC
>architecture did not work (4-register instruction). We did teach the C
>compiler that if it needed to clear more than one field in a
>container, it could do so in a single CLR instruction.
>
>Extract instructions were the left shift varietals, Make was the right
>shift varietal.
>
>These instructions were added to the AMD version of x86 about 4 years
>ago with the exception that one can directly insert (single
>instruction) in the AMD machines. Don't know about the Intel versions.
>
>What was the name of the architecture before Unisys renamed it to
>ClearPath?
>
>Mitch

Originally Burroughs Large System, then Burroughs (then Unisys) A-series.

All descendents of the B6700 (derived from the B5000).

With a stack architecture you don't have to worry about number of fields for 
addressing. :)

CDC machines had a mask instruction, along with NOT and rotate, bit fields 
weren't too bad (although it chewed up a few registers for temps).


Were the AMD instructions ever documented?

		- Tim

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

#1859

Tim McCaffrey <timcaffrey@aol.com> wrote:
...
> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
> All descendents of the B6700 (derived from the B5000).
> With a stack architecture you don't have to worry about number of fields for 
> addressing. :)
...

Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
Seems to have been needed for Algol's idea that i**j is integer if
j>=0 but real if j<0.

-- 
Scientists are always changing their story and as a Conservative, I
have no tolerance for ambiguity. [This proves science is lies].
-- BONZO@27-32-240-172 [100 nyms and counting], 14 Jan 2011 14:46 +1100

CORRECTION: True science, (remember that?) can be trusted, but this "science" is ALL LIES!
-- BONZO@27-32-240-172 [100 nyms and counting], 19 Feb 2011 14:46 +1100

You whackos [i.e. "scientists"] just keep changing your "predictions" to suit reality!
-- BONZO@27-32-240-172 [100 nyms and counting], 16 Feb 2011 15:57 +1100

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

#1860

In article <4ddeb187$0$22474$afc38c87@news.optusnet.com.au>,
 <kym@kymhorsell.com> wrote:
>Tim McCaffrey <timcaffrey@aol.com> wrote:
>...
>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>> All descendents of the B6700 (derived from the B5000).
>> With a stack architecture you don't have to worry about number of fields for 
>> addressing. :)
>...
>
>Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>Seems to have been needed for Algol's idea that i**j is integer if
>j>=0 but real if j<0.

Not at all.  Making integers simply floating-point with a fixed
exponent was pretty common, not just on Burroughs.


Regards,
Nick Maclaren.

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

#1861

nmm1@cam.ac.uk wrote:
> In article <4ddeb187$0$22474$afc38c87@news.optusnet.com.au>,
> <kym@kymhorsell.com> wrote:
>>Tim McCaffrey <timcaffrey@aol.com> wrote:
>>...
>>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>>> All descendents of the B6700 (derived from the B5000).
>>> With a stack architecture you don't have to worry about number of fields for 
>>> addressing. :)
>>...
>>Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>>Seems to have been needed for Algol's idea that i**j is integer if
>>j>=0 but real if j<0.
> Not at all.  Making integers simply floating-point with a fixed
> exponent was pretty common, not just on Burroughs.

I worked in 5500's and 6700s in the 60s and 70s. I don't recall any other 
machine available to me at the time (CDC 3600, HP2000, PDP11) that 
"sacrified" 8 bits or more of integer range to handle compatibility with reals.

But by "peculiar" I meant wrt to what youngsters would understand cf today.

-- 
[A record is not a record if it is too old or if it is any other
record than the one I count as any kind of record:].
The Austrailian floods weren't even record breaking.
...you have failed to counter the points I have brought up, such as
there not being an accurate way to measure flooded area 170 years ago
and the fact that insurance claims and deaths are an indication of
population and infrastructure as much as the magnitude of the flood.
-- Monkey Clumps <spacebrain71@yahoo.com>, 1 Feb 2011 09:01 -0800

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

#1862

In article <4ddeb4ad$0$29364$afc38c87@news.optusnet.com.au>,
 <kym@kymhorsell.com> wrote:
>>>...
>>>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>>>> All descendents of the B6700 (derived from the B5000).
>>>> With a stack architecture you don't have to worry about number of fields for 
>>>> addressing. :)
>>>...
>>>Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>>>Seems to have been needed for Algol's idea that i**j is integer if
>>>j>=0 but real if j<0.
>> Not at all.  Making integers simply floating-point with a fixed
>> exponent was pretty common, not just on Burroughs.
>
>I worked in 5500's and 6700s in the 60s and 70s. I don't recall any other 
>machine available to me at the time (CDC 3600, HP2000, PDP11) that 
>"sacrified" 8 bits or more of integer range to handle compatibility with reals.

If I recall, the CDC 6600 and 7600 did.  I can't recall the others.

>But by "peculiar" I meant wrt to what youngsters would understand cf today.

Oh, right - bvut that covers almost EVERYTHING :-)


Regards,
Nick Maclaren.

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

#1864

nmm1@cam.ac.uk wrote:
> In article <4ddeb4ad$0$29364$afc38c87@news.optusnet.com.au>,
> <kym@kymhorsell.com> wrote:
>>>>...
>>>>> Originally Burroughs Large System, then Burroughs (then Unisys) A-series.
>>>>> All descendents of the B6700 (derived from the B5000).
>>>>> With a stack architecture you don't have to worry about number of fields for 
>>>>> addressing. :)
>>>>...
>>>>Had a lot of peculiarities. Integer numbers just reals with 0 exponent.
>>>>Seems to have been needed for Algol's idea that i**j is integer if
>>>>j>=0 but real if j<0.
>>> Not at all.  Making integers simply floating-point with a fixed
>>> exponent was pretty common, not just on Burroughs.
>>
>>I worked in 5500's and 6700s in the 60s and 70s. I don't recall any other 
>>machine available to me at the time (CDC 3600, HP2000, PDP11) that 
>>"sacrified" 8 bits or more of integer range to handle compatibility with reals.
> If I recall, the CDC 6600 and 7600 did.  I can't recall the others.

I seem to recall some of the later "Cybers" did something like that.

>>But by "peculiar" I meant wrt to what youngsters would understand cf today.
> Oh, right - bvut that covers almost EVERYTHING :-)

If I resort to tautology I find I can't go far wrong. :)

48-bit words, 6-bit company-specific character set, 39 bits of integer 
precision, assynetric reals from 8.75@-47 to 4.3@68, the B5500 was like 
an alien world cf today.

-- 
What, exactly, are you complaining about. [...] So, what's the complaint?
-- John Stafford <nhoj@droffats.net>, 09 Dec 2010 16:30:53 -0600

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

#1865

kym@kymhorsell.com wrote:
[Burroughs]

Of course, mainframes built in Detroit was another "peculiarity".

-- 
You are now in the killfile.
[2 weeks later:]
Oh come on now. That little post should not have upset you so. I
only meant for you to ponder the future.
-- John Stafford <nhoj@droffats.net> (AKA A Moose In Love 
<parkstreetbooboo@gmail.com>), 21 Dec 2010 22:33:45 -0800 

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

#1867

In article <4ddebe5b$0$13392$afc38c87@news.optusnet.com.au>,
 <kym@kymhorsell.com> wrote:
>
>>>But by "peculiar" I meant wrt to what youngsters would understand cf today.
>> Oh, right - bvut that covers almost EVERYTHING :-)
>
>If I resort to tautology I find I can't go far wrong. :)
>
>48-bit words, 6-bit company-specific character set, 39 bits of integer 
>precision, assynetric reals from 8.75@-47 to 4.3@68, the B5500 was like 
>an alien world cf today.

Oh, I am not denying THAT :-)  But so were many of the machines
of that era, though I accept that the Burroughs was further removed
from a modern x86 system than most ....


Regards,
Nick Maclaren.

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

#1868

kym@kymhorsell.com wrote:
> If I resort to tautology I find I can't go far wrong. :)
>
> 48-bit words, 6-bit company-specific character set, 39 bits of integer
> precision, assynetric reals from 8.75@-47 to 4.3@68, the B5500 was like
> an alien world cf today.

I remember 39-bit words, two instructions/word (yup), 8K architectural
maximum core.

Do today's kids even know what a "core dump" is, or why we have
"bootstrap" loaders? Or how you could encode alpha_numeric characters
into 5 bit paper tape?

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

Page 1 of 3  [1] 2 3  Next page →

Back to top | Article view | comp.arch

csiph-web