Megalextoria
Retro computing and gaming, sci-fi books, tv and movies and other geeky stuff.

Home » Digital Archaeology » Computer Arcana » Computer Folklore » Micros as number crunchers
Show: Today's Messages :: Show Polls :: Message Navigator
E-mail to friend 
Switch to threaded view of this topic Create a new topic Submit Reply
Re: Micros as number crunchers [message #393686 is a reply to message #393674] Tue, 21 April 2020 18:22 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: J. Clarke

On Tue, 21 Apr 2020 13:19:28 -0700, Peter Flass
<peter_flass@yahoo.com> wrote:

> J. Clarke <jclarke.873638@gmail.com> wrote:
>> On Mon, 20 Apr 2020 21:24:30 -0400, Dan Espen <dan1espen@gmail.com>
>> wrote:
>>
>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>
>>>> On Sunday, April 19, 2020 at 7:36:54 PM UTC-6, John Levine wrote:
>>>>
>>>> > For that matter, if 36 bits was enough why did the CDC supercomputers have
>>>> > 60 bit words?
>>>>
>>>> 36 bits was enough some of the time, but IBM's 32 bits on the 360 was almost
>>>> never enough. Whether or not a better-designed 32-bit float would be good enough
>>>> to bring back some of the applications lost is not clear to me.
>>>
>>> I never, ever had to use a float on a mainframe but I believe you could
>>> use 64 bit floats from the beginning.
>>
>> Alas my green card and assembler text are in my desk at work, which
>> will not be accessible to me until this blasted virus is done.
>>
>
> I think all that stuff is available online, somewhere.

I'm sure it is, it's just more effort than I want to go through for a
casual discussion.
Re: old cruddy floating point, Micros as number crunchers [message #393687 is a reply to message #393685] Tue, 21 April 2020 19:55 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
J. Clarke <jclarke.873638@gmail.com> writes:
> On Tue, 21 Apr 2020 21:19:19 -0000 (UTC), John Levine
> <johnl@taugh.com> wrote:

>>
>> Fun fact: on a 360/30 a long floating divide took about 2ms, and I
>> don't mean 2us.
>
> Divides tend to take a lot of cycles.

Some divides. Others, like by a power of two, are simple right shift operations.

Burroughs Medium systems, division by a power of ten was a simple BCD move,
likewise multiplication.
Re: Why 8-bit bytes, Micros as number crunchers [message #393688 is a reply to message #393684] Tue, 21 April 2020 19:56 Go to previous messageGo to next message
scott is currently offline  scott
Messages: 4237
Registered: February 2012
Karma: 0
Senior Member
John Levine <johnl@taugh.com> writes:
>>> Why are eight-bit bytes so common today?
>
> We don't have to guess, since we can read the April 1964 IBM Systems
> Journal article "Architecture of the IBM System/360".
>
> They wanted it to be character addressable for commercial programs, so
> they had to decide between 6 and 8 bit bytes. They said the deciding
> factor was that they could store two BCD digits in an 8 bit byte, and
> there was a lot more numeric than alphabetic data at the time. They
> also mentioned allowing a larger alphabetic character set (they knew
> that STRETCH had upper and lower case) and it fit with their decision
> to do 32/64 bit floats rather than 48, and 16 bit instruction fields.
>
> Since the 360 was such a huge success, other systems copied its
> addressing architecture. I have never been able to figure out why DEC
> made the PDP-11 little-endian rather than big-endian, despite looking
> through a lot of books and papers.

Even Burroughs moved 6-bit BCD to 8-bit EBCDIC to be compatible with IBM peripherals.
Re: Micros as number crunchers [message #393689 is a reply to message #393652] Tue, 21 April 2020 22:32 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Tuesday, April 21, 2020 at 11:17:58 AM UTC+10, Dan Espen wrote:
> Quadibloc <j.....@ecn.ab.ca> writes:
>
>> On Sunday, April 19, 2020 at 7:04:34 AM UTC-6, Thomas Koenig wrote:
>>
>>> Was it the Arpanet? Octet-based from the start, as far as I know.
>>
>> The octet became ubiquitous long before the Arpanet.
>>
>> My previous post recounts some of the history - the IBM 360 set the
>> stage for the PDP-11.
>>
>> One thing I didn't mention was that before the 360, IBM made a
>> high-performance scientific computer called the STRETCH. One unusual
>> feature it had was that some instructions actually addressed memory by
>> the *bit* rather than by the word or the byte.
>>
>> Therefore, since it was a binary machine, it had a word size of 64
>> bits, so that bit addressing would work easily: the last six bits
>> pointed to the bit within a word. While the System/360 didn't have
>> that feature, they may have thought they might need to add it later.
>
> S/360 was pretty good at bit access. You did bit shifting in registers
> and sometimes used EX to give a bit count to the shift instruction.
> There were lots of bit test/set instructions.
>
> I'm not reading POPs right now but I don't think IBM has added any
> storage to storage bit shifting stuff since S/360 days.
>
>> When designing the System/360, another thought was its use for
>> business computations. The IBM 1401 stored numbers as printable
>> character strings. This wasted two bits out of every six, since you
>> only need four bits to represent a decimal digit.
>
> BCD uses 4 bits for digits as it should. I was going to say BCD wasted
> a bit for the sign (it uses 2 bits), but I guess we needed plus, minus,
> and unsigned.
>
> So, BCD was pretty good at storing and using numbers.
>
>> The IBM 360 could handle both binary numbers and packed decimal
>> numbers, where two decimal digits, each four bits long, were in every
>> 8-bit byte. When you *unpack* a decimal number, you get its printable
>> character form as a string of EBCDIC digits.
>>
>> So this meant it could do decimal arithmetic and instead of changing
>> 33% waste to 50% waste, it eliminated the waste entirely. (Well, not
>> _entirely_, as ten possible digits don't use all sixteen possibilities
>> of four bits.
>
> Other waste was the 4 bit sign and the possible unneeded extra 4 bits
> for the required odd number of digits.
>
> Still, IBMs packed decimal was highly efficient for it's intended use.
>
>> IBM got around to dealing with that, through Chen-Ho encoding, and its
>> later variant Densely Packed Decimal, DPD, but that is another story.)
>
> Never heard of DPD but looked it up. Never heard of any IBM system
> using it.
>
>> That was the rationale used for the 8-bit byte at the time the 360 was
>> being designed. Perhaps because of the STRETCH and bit addressing, a
>> machine with a 48-bit word that could use _both_ 6-bit characters and
>> 8-bit characters was not considered.
>
> I worked as a programmer though the IBM 14xx to S/360 era.
>
> I remember lower case support was a big factor in the 6 to 8 bit change.
> So was IBMs aborted attempt to support ASCII which was already at 7
> bits. So, some increase was already built into S/360.
>
> IBMs lower case support was slow in coming. I do remember places having
> 129 keypunches with lower case support. The printers could do lower
> case but lower case trains were uncommon.

Sites could use any of the available print trains.
Upper and Lower case was just one of them, and our site had this chain too.

> The first IBM CRT the 2260 was upper case only. So were the first
> 3270s. I did a mainframe project in 70-71 where we had to use Bunker
> Ramo CRTS to get the required lower case support.
>
> I remember a mainframe C/370 project around 1995. When we first started
> looking at printed core dumps we couldn't see any lower case in the
> character dumps. We had to change an option somewhere in the guts of
> MVS to tell MVS to print lower case wasn't unprintable. As we shipped
> this stuff to customers we soon learned to ask our customers to make the
> same change. So as late as 1995 some number of sites didn't do much
> with lower case.
>
> Then there is the infamous a/A key on real 3270s. Turn this to "A" and
> any lower case in your data looks like upper case. Why would you want
> to see what your data actually looked like.
Re: old cruddy floating point, Micros as number crunchers [message #393690 is a reply to message #393680] Wed, 22 April 2020 01:22 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2020-04-21, John Levine <johnl@taugh.com> wrote:

> Fun fact: on a 360/30 a long floating divide took about 2ms, and I
> don't mean 2us.

Did the 360/30 even have floating point instructions? Or were they
emulated in software?

In the Univac world, if you were really cheap you could order your
9200 or 9300 (their answer to the 360/20) without MP, DP, or ED
instructions. If you needed the functionality, you'd link a
software library that emulated the instructions, and precede
each such instruction with BAL 15,MPDP or BAL 15,EDIT as appropriate.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: Micros as number crunchers [message #393691 is a reply to message #393689] Wed, 22 April 2020 01:25 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2020-04-22, robin.vowels@gmail.com <robin.vowels@gmail.com> wrote:

> On Tuesday, April 21, 2020 at 11:17:58 AM UTC+10, Dan Espen wrote:
>
>> IBMs lower case support was slow in coming. I do remember places having
>> 129 keypunches with lower case support. The printers could do lower
>> case but lower case trains were uncommon.
>
> Sites could use any of the available print trains.
> Upper and Lower case was just one of them, and our site had this chain too.

When you mounted the TN train to get lower case, your printing speed
went way down, though. Most shops rightfully resented the loss of
productivity if you were to leave it in all the time.

I worked in Univac shops, but the situation was similar. I don't know
of anyone who used a lower-case print band (if such a thing was even
available, I'd have to dig out the manuals), but one shop wanted to
switch between 48- and 63-character bands to get that extra little
bit of speed. Fortunately, we managed to convince them that the
slight time saving from printing what reports would look OK with
a 48-character band would be more than offset by the time required
to switch bands when they wanted reports that needed the full
63-character set - even if the operator wasn't out for coffee
when the band change request came up.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: old cruddy floating point, Micros as number crunchers [message #393692 is a reply to message #393690] Wed, 22 April 2020 06:28 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, April 21, 2020 at 11:23:30 PM UTC-6, Charlie Gibbs wrote:
> On 2020-04-21, John Levine <johnl@taugh.com> wrote:
>
>> Fun fact: on a 360/30 a long floating divide took about 2ms, and I
>> don't mean 2us.
>
> Did the 360/30 even have floating point instructions? Or were they
> emulated in software?

Good question. IBM System/360 Model 30 Functional Characteristics should contain
an answer...

it states that the standard set, the commercial set, the scientific set, and the
commercial set of instructions were all available for the machine. So if you
paid for floating-point on your machine, IBM would do something to ensure that
floating-point instructions in your programs got executed.

Since the Model 30 was microprogrammed, and IBM made its computers
microprogrammable specifically to allow the same instruction set to be used on
the small models as well as the large, I would _presume_ that IBM would use
microcode, rather than trap routines, to do the floating-point instructions, but
maybe the Model 30 might have had very limited microcode capacity.

I also have a copy of Microprogramming: Principles and Practices by Samir S.
Husson handy. It describes the microcode format of the Model 25, which was
derived from the Model 30, in a brief note, but otherwise does not help to
resolve the question.

John Savard
Re: Why 8-bit bytes, Micros as number crunchers [message #393693 is a reply to message #393684] Wed, 22 April 2020 07:02 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Andy Walker

On 21/04/2020 23:07, John Levine wrote:
> [...] I have never been able to figure out why DEC
> made the PDP-11 little-endian rather than big-endian, despite looking
> through a lot of books and papers.

I had a lot of trouble understanding the PDP 11 until I
realised that it made more sense to imagine storage right-to-left;
that is, bytes were numbered

... 10 9 8 7 6 5 4 3 2 1 0 [-1 -2 ...]

rather than

[... -1 -2] 1 0 3 2 5 4 7 6 9 8 11 ...

--
Andy Walker,
Nottingham.
Re: Micros as number crunchers [message #393694 is a reply to message #393681] Wed, 22 April 2020 07:09 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Andy Walker

On 21/04/2020 22:54, Douglas Miller wrote:
> On Tuesday, April 21, 2020 at 4:02:21 PM UTC-5, Dan Espen wrote:
>> 52 of the 64 bit patterns only leaves 12 symbols. [...]
> Your math is based on a misconception. There are only 26 alphabetic
> symbols. There are codes to "shift up" and "shift down" (or some
> equivalent) so UC and LC do not both take up codes. In fact, the
> special characters and digits are also predicated by shifting, so you
> have closer to 128 symbols possible, total.

Yes. There is a code table at [eg]

https://ub.fnwi.uva.nl/computermuseum/pictures/flexowrcode.g if

Their codes differ somewhat from the ones we had -- our machines
included half, pi, squared, alpha and beta, and perhaps others I've
forgotten -- but it shows the idea. The order looks illogical in
the Gif, but that's because of the parity bit.

--
Andy Walker,
Nottingham.
Re: Micros as number crunchers [message #393707 is a reply to message #393671] Wed, 22 April 2020 11:30 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: JimP

On 21 Apr 2020 20:05:39 GMT, Jorgen Grahn <grahn+nntp@snipabacken.se>
wrote:
> On Tue, 2020-04-21, Charlie Gibbs wrote:
>> On 2020-04-21, Dan Espen <dan1espen@gmail.com> wrote:
>>
>>> Quadibloc <jsavard@ecn.ab.ca> writes:
>>>
>>>> On Monday, April 20, 2020 at 6:45:06 PM UTC-6, Peter Flass wrote:
>>>>
>>>> > No one will ever want two cases.;-)
>>>>
>>>> Of course, if we all spoke Georgian...
>>>
>>> Back in my 1401 days I thought computers
>>> should NEVER support lower case.
>>>
>>> I DIDN'T SEE ANY PROBLEM IN HUMANS ADAPTING TO AN ALL UPPER CASE WORLD.
>>
>> There was a bit of a mystique in those days. Even well into the
>> '80s, many people could not bring themselves to use lower case,
>> perhaps believing that it was somehow not legitimate.
>> (I confess, I found the thought of writing assembly language
>> in lower case to be somewhat blasphemous, and those Algol
>> people looked as if they weren't taking things seriously.)
>
> I must have had a brief period like that, but with Unix and the Amiga
> I bought the whole lowercase concept. It still looks elegant,
> readable and modern to me.
>
> BTW, I had a strange experience at a previous (but recent) workplace.
> I had to print some data in hex, and naturally chose lower case hex,
> e.g. 0x0f1e. The others however found that odd: they wanted me to
> change it to 0x0F1E. I thought it was a joke at first, but they
> insisted; they really found the lowercase form odd. A Windows thing,
> perhaps?
>
> /Jorgen

I've seen lower case hexadecimal in Windows. Must have been the people
wanting it.

--
Jim
Re: old cruddy floating point, Micros as number crunchers [message #393708 is a reply to message #393692] Wed, 22 April 2020 12:44 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <7d015977-edc5-47ba-95d8-fba064801488@googlegroups.com>,
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, April 21, 2020 at 11:23:30 PM UTC-6, Charlie Gibbs wrote:
>> On 2020-04-21, John Levine <johnl@taugh.com> wrote:
>>
>>> Fun fact: on a 360/30 a long floating divide took about 2ms, and I
>>> don't mean 2us.
>>
>> Did the 360/30 even have floating point instructions? Or were they
>> emulated in software?

The whole computer was emulated in microcode. When it did disk
operations the microcode was so busy being the channel that the CPU
pretty much stopped. If you ordered the floating point feature, it
had floating point instructions. If you ordered the 1401 emulator, it
had 1401 instructions and a few poorly documented 360 instructions to
manage the emulation.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Micros as number crunchers [message #393709 is a reply to message #393650] Wed, 22 April 2020 13:39 Go to previous messageGo to next message
usenet is currently offline  usenet
Messages: 556
Registered: May 2013
Karma: 0
Senior Member
On Mon, 20 Apr 2020 17:54:01 -0700, Peter Flass <peter_flass@yahoo.com> wrote:
> Peter Flass <peter_flass@yahoo.com> wrote:
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>> On Sunday, April 19, 2020 at 7:04:34 AM UTC-6, Thomas Koenig wrote:
>>>> Was it the Arpanet? Octet-based from the start, as far as I know.
>>>
>>> The octet became ubiquitous long before the Arpanet.
>>>
>>> My previous post recounts some of the history - the IBM 360 set the stage for
>>> the PDP-11.
>>>
>>> One thing I didn't mention was that before the 360, IBM made a high-performance
>>> scientific computer called the STRETCH. One unusual feature it had was that some
>>> instructions actually addressed memory by the *bit* rather than by the word or
>>> the byte.
>>
>> The iAPX432 did this too. IMHO it adds a lot of complexity for little or no
>> benefit.
>
> OTOH it's nice to have instructions to manipulate bits without masking and
> shifting. The PDP-10 had good instructions, but, AFAIK, they were limited
> to a single word.

Yes, and that was never a problem. I never saw an application with a stream of
odd length bytes such that there was a lot of wasted space in each word. Text
was mostly seven-bit ASCII (one bit left over in each word) or occasionally
SIXBIT. Otherwise you were taking and placing fields from/to records. The
PDP-10 was very much a word-oriented machine, and consequently aligning things
to word boundries is very advantageous. Fields bigger than a single word were
usually just multiple words.


> The Altos had BITBLT (IIRC). It's not simple to move an
> odd-length bit strings where the source and destination begin on different
> bits in a word or byte.
Re: Micros as number crunchers [message #393712 is a reply to message #393522] Wed, 22 April 2020 17:48 Go to previous messageGo to next message
Jon Elson is currently offline  Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
Senior Member
Thomas Koenig wrote:

> Thomas Koenig <tkoenig@netcologne.de> schrieb:
>> Also interesting is the fact that a C64 was around a factor of 2000
>> slower than a VAX 11/780 (with the C64 using optimized assembly).
>
> Correction: That number was for BASIC. For optimized assembly,
> it was around 330 times slower.
A VAX 11/780 in about 1981 was about $200K, or $250 K for a complete system.

Jon
Re: Micros as number crunchers [message #393713 is a reply to message #393561] Wed, 22 April 2020 17:52 Go to previous messageGo to next message
Jon Elson is currently offline  Jon Elson
Messages: 646
Registered: April 2013
Karma: 0
Senior Member
Thomas Koenig wrote:


>
> There was a good reason why the old IBM scientific machines had
> 36 bit floating point, but that was sacrificed on the altar of
> the all-round system, the 360.

But, they botched it even worse on the 360. Single precision float had a
24-bit mantissa, but they normalized in 4-bit steps. So, any particular
result could have up to 3 most significant zeroes in the mantissa,
squeezing out up to 3 bits of precision. This allowed the exponent to
cover an 8X larger range, as it was a power of 16, not power of 2.

This played hob with numerical approximations by iteration, as when you got
close to the final result, the random jumping of precision was bigger than
the epsilon of the approximation.

Jon
Re: Micros as number crunchers [message #393714 is a reply to message #393635] Wed, 22 April 2020 18:31 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Ray

scott@slp53.sl.home (Scott Lurndal) writes:

> John Levine <johnl@taugh.com> writes:
>> In article <r7k08o$9gh$1@newsreader4.netcologne.de>,
>> Thomas Koenig <tkoenig@netcologne.de> wrote:
>>>> The PDP-11 was indeed byte oriented, but Unix originally started on the
>>>> 18-bit PDP-7.
>>
>> It hopped to the PDP-11 very early, wasn't any 18-bitisms I could see in 1975.
>>
>>> ... which is why octal plays such an important role in Unix and C,
>>> instead of hexadecimal.
>>
>> Nope. DEC always used octal in their PDP-11 software and
>> documentation. Since it had 8 registers, three-bit octal digits in
>> the opcodes were handy.
>
> I suspect that the PDP-11 choice of Octal was a function of the fact
> that both PDP-10 and PDP-8 (and -5, et alia) had word bit-lengths congruent
> to zero modulo three.

This has just reminded me of a funny thing from the 80's. After I had
spent a few months programing in octal on PDP 11/43's and 11/73's and
thrown all my 8's and 9's out of the window... I found I had a problem
helping my 2 boys with their homework because my decimal skills had
faded a little. Grin

RayH (the other one)
Re: Micros as number crunchers [message #393715 is a reply to message #393707] Wed, 22 April 2020 18:50 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Wednesday, April 22, 2020 at 9:30:54 AM UTC-6, JimP wrote:

> I've seen lower case hexadecimal in Windows. Must have been the people
> wanting it.

IBM mainframes used to always use upper-case hexadecimal. On the other hand, the
convention in C is to use lower-case hexadecimal. I would expect Windows to follow
C in doing what is popular nowadays.

John Savard
Re: Micros as number crunchers [message #393716 is a reply to message #393671] Wed, 22 April 2020 18:55 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, April 21, 2020 at 2:05:42 PM UTC-6, Jorgen Grahn wrote:

> BTW, I had a strange experience at a previous (but recent) workplace.
> I had to print some data in hex, and naturally chose lower case hex,
> e.g. 0x0f1e. The others however found that odd: they wanted me to
> change it to 0x0F1E. I thought it was a joke at first, but they
> insisted; they really found the lowercase form odd. A Windows thing,
> perhaps?

As others have noted, Windows isn't the culprit.

The current standard for hexadecimal, with the letters from A through F as the
additional digits, originated with the IBM System/360, and it consistently used
only the upper-case letters, both on the computer and in documentation.

On the other hand, much later, Unix and C used lower-case hexadecimal, and
Windows is in the modern camp with those.

Before the System/360 came along, a few other computers used hexadecimal instead of octal, but they often used a *different* set of letters for the extra digits.

Here are the examples

Bendix G-15, SWAC u v w x y z
Monrobot XI S T U V W X
Datamatic D-1000 b c d e f g
Elbit 100 B C D E F G
LGP-30 f g j k q w
ILLIAC k s n j f l
Pacific Data Systems 1020 L C A S M D

that I've listed on my web page at
http://www.quadibloc.com/comp/cp02.htm

John Savard
Re: Why 8-bit bytes, Micros as number crunchers [message #393717 is a reply to message #393684] Wed, 22 April 2020 19:00 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Tuesday, April 21, 2020 at 4:07:07 PM UTC-6, John Levine wrote:
> I have never been able to figure out why DEC
> made the PDP-11 little-endian rather than big-endian, despite looking
> through a lot of books and papers.

I agree that little-endian is an unfortunate choice.

I've learned that DEC was so successful as a computer company because its prices
were lower.

If you add two numbers together that are longer than a computer word, little-
endian order lets you fetch two things you can add right away, having the carry
ready for the next step.

Putting the two character bytes in the 16-bit word in little-endian order then
lets you make the machine as consistent as a big-endian one.

So I've always felt that that's all the explanation that is needed; fetching the
end of the number first would have taken a little extra circuit complexity.

John Savard
Re: Micros as number crunchers [message #393718 is a reply to message #393716] Wed, 22 April 2020 19:27 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Douglas Miller

On Wednesday, April 22, 2020 at 5:55:21 PM UTC-5, Quadibloc wrote:
> ...
>
> Before the System/360 came along, a few other computers used hexadecimal instead of octal, but they often used a *different* set of letters for the extra digits.
>
> Here are the examples
>
> Bendix G-15, SWAC u v w x y z
> Monrobot XI S T U V W X
> Datamatic D-1000 b c d e f g
> Elbit 100 B C D E F G
> LGP-30 f g j k q w
> ILLIAC k s n j f l
> Pacific Data Systems 1020 L C A S M D
>
> that I've listed on my web page at
> http://www.quadibloc.com/comp/cp02.htm
>
> John Savard

Curious choices for the hexadecimal digits beyond '9'. I assume these machines did not use ASCII, so did their choice of hex digits have to do with the binary values of the chosen letters? Just seems more like accidental/incidental decoding than a logical, intentional, choice.
Re: old cruddy floating point, Micros as number crunchers [message #393719 is a reply to message #393708] Wed, 22 April 2020 19:29 Go to previous messageGo to next message
Dan Espen is currently offline  Dan Espen
Messages: 3867
Registered: January 2012
Karma: 0
Senior Member
John Levine <johnl@taugh.com> writes:

> In article <7d015977-edc5-47ba-95d8-fba064801488@googlegroups.com>,
> Quadibloc <jsavard@ecn.ab.ca> wrote:
>> On Tuesday, April 21, 2020 at 11:23:30 PM UTC-6, Charlie Gibbs wrote:
>>> On 2020-04-21, John Levine <johnl@taugh.com> wrote:
>>>
>>>> Fun fact: on a 360/30 a long floating divide took about 2ms, and I
>>>> don't mean 2us.
>>>
>>> Did the 360/30 even have floating point instructions? Or were they
>>> emulated in software?
>
> The whole computer was emulated in microcode. When it did disk
> operations the microcode was so busy being the channel that the CPU
> pretty much stopped. If you ordered the floating point feature, it
> had floating point instructions. If you ordered the 1401 emulator, it
> had 1401 instructions and a few poorly documented 360 instructions to
> manage the emulation.

I found the documentation for those instructions in one of those big
CE looseleafs.
I ended up using one of those instructions in an application program
that was reading 1401 tape data in load mode. The instruction needed
256 byte alignment on a data area to work correctly. That was the
instruction that blew up when the customer installed floating point.
The floating point save area moved the program origin away from the
256 byte aligned area I needed.

I figured out how to get alignment without worrying about program origin.

--
Dan Espen
Re: Which end of the egg, was 8-bit bytes, Micros as number crunchers [message #393721 is a reply to message #393717] Wed, 22 April 2020 20:37 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <3d852844-7433-41a9-a658-eb32b9d132ee@googlegroups.com>,
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, April 21, 2020 at 4:07:07 PM UTC-6, John Levine wrote:
>> I have never been able to figure out why DEC
>> made the PDP-11 little-endian rather than big-endian, despite looking
>> through a lot of books and papers.

> If you add two numbers together that are longer than a computer word, little-
> endian order lets you fetch two things you can add right away, having the carry
> ready for the next step.

That wasn't it. The PDP-11 had 16 bit internal datapaths and the
early models didn't have any instructions that handled data longer
than a 16 bit word. When they added floating point in later models,
several of the formats were "middle endian" with the high word at the
lower address, even though within each word, the low byte was at the
lower address. It wasn't until the 8086 that anyone made a consistent
little-endian design.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Which end of the egg, was 8-bit bytes, Micros as number crunchers [message #393722 is a reply to message #393721] Wed, 22 April 2020 20:57 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Douglas Miller

On Wednesday, April 22, 2020 at 7:37:47 PM UTC-5, John Levine wrote:
> ... It wasn't until the 8086 that anyone made a consistent
> little-endian design.
>
> --
> Regards,
> John Levine, Primary Perpetrator of "The Internet for Dummies",
> Please consider the environment before reading this e-mail. https://jl.ly

Well, the 8080, at least. I'm not certain even that was the first, though. Seems likely at least one of the early character-oriented mainframes might have used it.
Re: Micros as number crunchers [message #393723 is a reply to message #393713] Wed, 22 April 2020 20:58 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 7:53:00 AM UTC+10, Jon Elson wrote:
> Thomas Koenig wrote:

>> There was a good reason why the old IBM scientific machines had
>> 36 bit floating point, but that was sacrificed on the altar of
>> the all-round system, the 360.
>
> But, they botched it even worse on the 360. Single precision float had a
> 24-bit mantissa, but they normalized in 4-bit steps. So, any particular
> result could have up to 3 most significant zeroes in the mantissa,
> squeezing out up to 3 bits of precision.

They didn\t "squeeze out" 3 bits of precision.
All that was guaranteed was 21 bits of mantissa.

> This allowed the exponent to
> cover an 8X larger range, as it was a power of 16, not power of 2.

That's right, up to around 10**75.

It also speeded up pre-normalisation and post-normalization;
at most, up to 5 shifts instead of 23 shifts otherwise.
It was a trade-off.

> This played hob with numerical approximations by iteration, as when you got
> close to the final result, the random jumping of precision was bigger than
> the epsilon of the approximation.

It worked fine.
Re: Micros as number crunchers [message #393724 is a reply to message #393716] Wed, 22 April 2020 21:01 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 8:55:21 AM UTC+10, Quadibloc wrote:
> On Tuesday, April 21, 2020 at 2:05:42 PM UTC-6, Jorgen Grahn wrote:
>
>> BTW, I had a strange experience at a previous (but recent) workplace.
>> I had to print some data in hex, and naturally chose lower case hex,
>> e.g. 0x0f1e. The others however found that odd: they wanted me to
>> change it to 0x0F1E. I thought it was a joke at first, but they
>> insisted; they really found the lowercase form odd. A Windows thing,
>> perhaps?
>
> As others have noted, Windows isn't the culprit.
>
> The current standard for hexadecimal, with the letters from A through F as the
> additional digits, originated with the IBM System/360, and it consistently used
> only the upper-case letters, both on the computer and in documentation.
>
> On the other hand, much later, Unix and C used lower-case hexadecimal, and
> Windows is in the modern camp with those.
>
> Before the System/360 came along, a few other computers used hexadecimal instead of octal, but they often used a *different* set of letters for the extra digits.

Pilot ACE and DEUCE used neither.
The written form was in groups of 5 bits, for zero up thru 31.

> Here are the examples
>
> Bendix G-15, SWAC u v w x y z
> Monrobot XI S T U V W X
> Datamatic D-1000 b c d e f g
> Elbit 100 B C D E F G
> LGP-30 f g j k q w
> ILLIAC k s n j f l
> Pacific Data Systems 1020 L C A S M D
>
> that I've listed on my web page at
> http://www.quadibloc.com/comp/cp02.htm
Re: Micros as number crunchers [message #393725 is a reply to message #393691] Wed, 22 April 2020 21:15 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-04-22, robin.vowels@gmail.com <robin.vowels@gmail.com> wrote:
>
>> On Tuesday, April 21, 2020 at 11:17:58 AM UTC+10, Dan Espen wrote:
>>
>>> IBMs lower case support was slow in coming. I do remember places having
>>> 129 keypunches with lower case support. The printers could do lower
>>> case but lower case trains were uncommon.
>>
>> Sites could use any of the available print trains.
>> Upper and Lower case was just one of them, and our site had this chain too.
>
> When you mounted the TN train to get lower case, your printing speed
> went way down, though. Most shops rightfully resented the loss of
> productivity if you were to leave it in all the time.
>
> I worked in Univac shops, but the situation was similar. I don't know
> of anyone who used a lower-case print band (if such a thing was even
> available, I'd have to dig out the manuals), but one shop wanted to
> switch between 48- and 63-character bands to get that extra little
> bit of speed.

Don’t recall what the slowdown was, maybe 1/3 to 1/2? I don’t think I
worked in a place with an U/C only printer since the 70’s.

> Fortunately, we managed to convince them that the
> slight time saving from printing what reports would look OK with
> a 48-character band would be more than offset by the time required
> to switch bands when they wanted reports that needed the full
> 63-character set - even if the operator wasn't out for coffee
> when the band change request came up.
>



--
Pete
Re: Micros as number crunchers [message #393726 is a reply to message #393709] Wed, 22 April 2020 21:15 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Questor <usenet@only.tnx> wrote:
> On Mon, 20 Apr 2020 17:54:01 -0700, Peter Flass <peter_flass@yahoo.com> wrote:
>> Peter Flass <peter_flass@yahoo.com> wrote:
>>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>>> On Sunday, April 19, 2020 at 7:04:34 AM UTC-6, Thomas Koenig wrote:
>>>> > Was it the Arpanet? Octet-based from the start, as far as I know.
>>>>
>>>> The octet became ubiquitous long before the Arpanet.
>>>>
>>>> My previous post recounts some of the history - the IBM 360 set the stage for
>>>> the PDP-11.
>>>>
>>>> One thing I didn't mention was that before the 360, IBM made a high-performance
>>>> scientific computer called the STRETCH. One unusual feature it had was that some
>>>> instructions actually addressed memory by the *bit* rather than by the word or
>>>> the byte.
>>>
>>> The iAPX432 did this too. IMHO it adds a lot of complexity for little or no
>>> benefit.
>>
>> OTOH it's nice to have instructions to manipulate bits without masking and
>> shifting. The PDP-10 had good instructions, but, AFAIK, they were limited
>> to a single word.
>
> Yes, and that was never a problem. I never saw an application with a stream of
> odd length bytes such that there was a lot of wasted space in each word. Text
> was mostly seven-bit ASCII (one bit left over in each word) or occasionally
> SIXBIT. Otherwise you were taking and placing fields from/to records. The
> PDP-10 was very much a word-oriented machine, and consequently aligning things
> to word boundries is very advantageous. Fields bigger than a single word were
> usually just multiple words.

I’m thinking mostly of bitmapped graphics, which wasn’t relevant to the
-10. Say you want to clip part of one image and overlay it on another, a’la
Photoshop. If the source starts in bit 3 of a word or byte, and the
destination on bit 5 there’s a whole lot of shifting and masking to get it
there, for a conceptually simple operation, and there’s no point where you
can just move the bytes or words. I think the C64 also had BITBLT. Maybe
the Commodore folks could say. an extension of the -10 instruction set to
use bit pointers instead of byte pointers would do the trick.

>
>
>> The Altos had BITBLT (IIRC). It's not simple to move an
>> odd-length bit strings where the source and destination begin on different
>> bits in a word or byte.
>
>



--
Pete
Re: Micros as number crunchers [message #393727 is a reply to message #393716] Wed, 22 April 2020 21:15 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Tuesday, April 21, 2020 at 2:05:42 PM UTC-6, Jorgen Grahn wrote:
>
>> BTW, I had a strange experience at a previous (but recent) workplace.
>> I had to print some data in hex, and naturally chose lower case hex,
>> e.g. 0x0f1e. The others however found that odd: they wanted me to
>> change it to 0x0F1E. I thought it was a joke at first, but they
>> insisted; they really found the lowercase form odd. A Windows thing,
>> perhaps?
>
> As others have noted, Windows isn't the culprit.
>
> The current standard for hexadecimal, with the letters from A through F as the
> additional digits, originated with the IBM System/360, and it consistently used
> only the upper-case letters, both on the computer and in documentation.
>
> On the other hand, much later, Unix and C used lower-case hexadecimal, and
> Windows is in the modern camp with those.
>
> Before the System/360 came along, a few other computers used hexadecimal
> instead of octal, but they often used a *different* set of letters for the extra digits.
>
> Here are the examples
>
> Bendix G-15, SWAC u v w x y z
> Monrobot XI S T U V W X
> Datamatic D-1000 b c d e f g
> Elbit 100 B C D E F G
> LGP-30 f g j k q w
> ILLIAC k s n j f l
> Pacific Data Systems 1020 L C A S M D
>
> that I've listed on my web page at
> http://www.quadibloc.com/comp/cp02.htm
>
> John Savard
>

Wow, obviously not mnemonic, maybe some hardware thing? How about T E V R F
N for Ten Eleven twelVe thIRteen Fourteen and fifteeN?

--
Pete
Re: bad floating point, Micros as number crunchers [message #393729 is a reply to message #393723] Wed, 22 April 2020 21:50 Go to previous messageGo to next message
John Levine is currently offline  John Levine
Messages: 1405
Registered: December 2011
Karma: 0
Senior Member
In article <28db727b-c583-4dab-a68b-465b896f8b6f@googlegroups.com>,
<robin.vowels@gmail.com> wrote:

[ about the 360's floating point ]
>
> That's right, up to around 10**75.
>
> It also speeded up pre-normalisation and post-normalization;
> at most, up to 5 shifts instead of 23 shifts otherwise.
> It was a trade-off.

No question it was fast, but the wobbling precision and truncation were bad news.

>> This played hob with numerical approximations by iteration, as when you got
>> close to the final result, the random jumping of precision was bigger than
>> the epsilon of the approximation.
>
> It worked fine.

It was certainly possible to work around it with enough effort. IBM shipped
high quality numerical libraries that got very good results.



--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly
Re: Micros as number crunchers [message #393730 is a reply to message #393716] Wed, 22 April 2020 23:11 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: drb

> ILLIAC k s n j f l

For ILLIAC, MISTIC, and I suspect many of the IAS-machine derived
systems, I believe this was derived from the tape punch code in a
somewhat logical fashion. The mnemonic was "king sized numbers
just for laughs".

De
Re: Micros as number crunchers [message #393731 is a reply to message #393727] Thu, 23 April 2020 01:03 Go to previous messageGo to next message
Charlie Gibbs is currently offline  Charlie Gibbs
Messages: 5313
Registered: January 2012
Karma: 0
Senior Member
On 2020-04-23, Peter Flass <peter_flass@yahoo.com> wrote:

> Quadibloc <jsavard@ecn.ab.ca> wrote:
>
>> On Tuesday, April 21, 2020 at 2:05:42 PM UTC-6, Jorgen Grahn wrote:
>>
>>> BTW, I had a strange experience at a previous (but recent) workplace.
>>> I had to print some data in hex, and naturally chose lower case hex,
>>> e.g. 0x0f1e. The others however found that odd: they wanted me to
>>> change it to 0x0F1E. I thought it was a joke at first, but they
>>> insisted; they really found the lowercase form odd. A Windows thing,
>>> perhaps?
>>
>> As others have noted, Windows isn't the culprit.
>>
>> The current standard for hexadecimal, with the letters from A through
>> F as the additional digits, originated with the IBM System/360, and
>> it consistently used only the upper-case letters, both on the computer
>> and in documentation.
>>
>> On the other hand, much later, Unix and C used lower-case hexadecimal,
>> and Windows is in the modern camp with those.
>>
>> Before the System/360 came along, a few other computers used hexadecimal
>> instead of octal, but they often used a *different* set of letters for
>> the extra digits.
>>
>> Here are the examples
>>
>> Bendix G-15, SWAC u v w x y z
>> Monrobot XI S T U V W X
>> Datamatic D-1000 b c d e f g
>> Elbit 100 B C D E F G
>> LGP-30 f g j k q w
>> ILLIAC k s n j f l
>> Pacific Data Systems 1020 L C A S M D
>>
>> that I've listed on my web page at
>> http://www.quadibloc.com/comp/cp02.htm
>
> Wow, obviously not mnemonic, maybe some hardware thing? How about T E V R F
> N for Ten Eleven twelVe thIRteen Fourteen and fifteeN?

In grade 8 math we played with several different bases, all but one of
which were less than 10. For base twelve, however, we used T (ten) and
E (eleven) for the two topmost digits.

Five years later I was introduced to hexadecimal, IBM style (A-F).
Once, just for kicks, I performed long division in hex. It's one
of those things that you do just once.

--
/~\ Charlie Gibbs | Microsoft is a dictatorship.
\ / <cgibbs@kltpzyxm.invalid> | Apple is a cult.
X I'm really at ac.dekanfrus | Linux is anarchy.
/ \ if you read it the right way. | Pick your poison.
Re: bad floating point, Micros as number crunchers [message #393733 is a reply to message #393729] Thu, 23 April 2020 03:54 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 11:50:49 AM UTC+10, John Levine wrote:
> In article <28db727b-c583-4da........@googlegroups.com>,
> <r......@gmail.com> wrote:
>
> [ about the 360's floating point ]
>>
>> That's right, up to around 10**75.
>>
>> It also speeded up pre-normalisation and post-normalization;
>> at most, up to 5 shifts instead of 23 shifts otherwise.
>> It was a trade-off.
>
> No question it was fast, but the wobbling precision and truncation were bad news.

>>> This played hob with numerical approximations by iteration, as when you got
>>> close to the final result, the random jumping of precision was bigger than
>>> the epsilon of the approximation.
>>
>> It worked fine.
>
> It was certainly possible to work around it with enough effort.

No "work-around" was required. It worked fine as it was.

> IBM shipped
> high quality numerical libraries that got very good results.

There was a large library for both FORTRAN and PL/I.
Re: Micros as number crunchers [message #393734 is a reply to message #393723] Thu, 23 April 2020 04:17 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Koenig

robin.vowels@gmail.com <robin.vowels@gmail.com> schrieb:
> On Thursday, April 23, 2020 at 7:53:00 AM UTC+10, Jon Elson wrote:
>> Thomas Koenig wrote:
>
>>> There was a good reason why the old IBM scientific machines had
>>> 36 bit floating point, but that was sacrificed on the altar of
>>> the all-round system, the 360.
>>
>> But, they botched it even worse on the 360. Single precision float had a
>> 24-bit mantissa, but they normalized in 4-bit steps. So, any particular
>> result could have up to 3 most significant zeroes in the mantissa,
>> squeezing out up to 3 bits of precision.
>
> They didn\t "squeeze out" 3 bits of precision.
> All that was guaranteed was 21 bits of mantissa.

Which pretty much shortchanged the customers.

21 bits of precision out of a 32 bit float is far worse than could
have been done, especially for things like linear algebra.

>> This allowed the exponent to
>> cover an 8X larger range, as it was a power of 16, not power of 2.
>
> That's right, up to around 10**75.
>
> It also speeded up pre-normalisation and post-normalization;
> at most, up to 5 shifts instead of 23 shifts otherwise.
> It was a trade-off.

At the expense of the usability of the four-byte real number.

Having to use double precision for anything remotely useful, with
the much higher cost in memory and computation speed, is not really
a good thing.

>
>> This played hob with numerical approximations by iteration, as when you got
>> close to the final result, the random jumping of precision was bigger than
>> the epsilon of the approximation.
>
> It worked fine.

I fought it, eventually giving in and using double precision only.
Re: bad floating point, Micros as number crunchers [message #393735 is a reply to message #393733] Thu, 23 April 2020 04:18 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Thomas Koenig

robin.vowels@gmail.com <robin.vowels@gmail.com> schrieb:
> On Thursday, April 23, 2020 at 11:50:49 AM UTC+10, John Levine wrote:
>> In article <28db727b-c583-4da........@googlegroups.com>,
>> <r......@gmail.com> wrote:
>>
>> [ about the 360's floating point ]
>>>
>>> That's right, up to around 10**75.
>>>
>>> It also speeded up pre-normalisation and post-normalization;
>>> at most, up to 5 shifts instead of 23 shifts otherwise.
>>> It was a trade-off.
>>
>> No question it was fast, but the wobbling precision and truncation were bad news.
>
>>>> This played hob with numerical approximations by iteration, as when you got
>>>> close to the final result, the random jumping of precision was bigger than
>>>> the epsilon of the approximation.
>>>
>>> It worked fine.
>>
>> It was certainly possible to work around it with enough effort.
>
> No "work-around" was required. It worked fine as it was.

Did you ever implement linear equation solvers? If so, up to how
many equations did you manage to solve?

>
>> IBM shipped
>> high quality numerical libraries that got very good results.
>
> There was a large library for both FORTRAN and PL/I.

I used NAG, but that was much later.
Re: Micros as number crunchers [message #393737 is a reply to message #393734] Thu, 23 April 2020 06:06 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 6:17:26 PM UTC+10, Thomas Koenig wrote:
> <r.....@gmail.com> schrieb:
>> On Thursday, April 23, 2020 at 7:53:00 AM UTC+10, Jon Elson wrote:
>>> Thomas Koenig wrote:
>>
>>>> There was a good reason why the old IBM scientific machines had
>>>> 36 bit floating point, but that was sacrificed on the altar of
>>>> the all-round system, the 360.
>>>
>>> But, they botched it even worse on the 360. Single precision float had a
>>> 24-bit mantissa, but they normalized in 4-bit steps. So, any particular
>>> result could have up to 3 most significant zeroes in the mantissa,
>>> squeezing out up to 3 bits of precision.
>>
>> They didn\t "squeeze out" 3 bits of precision.
>> All that was guaranteed was 21 bits of mantissa.
>
> Which pretty much shortchanged the customers.
>
> 21 bits of precision out of a 32 bit float is far worse than could
> have been done, especially for things like linear algebra.

Really? GEORGE used 20 bits of mantissa in a 32-bit word.

>>> This allowed the exponent to
>>> cover an 8X larger range, as it was a power of 16, not power of 2.
>>
>> That's right, up to around 10**75.
>>
>> It also speeded up pre-normalisation and post-normalization;
>> at most, up to 5 shifts instead of 23 shifts otherwise.
>> It was a trade-off.
>
> At the expense of the usability of the four-byte real number.

Rubbish.

> Having to use double precision for anything remotely useful, with
> the much higher cost in memory and computation speed, is not really
> a good thing.

You exaggerate.

>>> This played hob with numerical approximations by iteration, as when you got
>>> close to the final result, the random jumping of precision was bigger than
>>> the epsilon of the approximation.
>>
>> It worked fine.
>
> I fought it, eventually giving in and using double precision only.

Pretty well most of us seem to have got by with single precision.
Re: bad floating point, Micros as number crunchers [message #393738 is a reply to message #393735] Thu, 23 April 2020 06:16 Go to previous messageGo to next message
Robin Vowels is currently offline  Robin Vowels
Messages: 426
Registered: July 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 6:18:57 PM UTC+10, Thomas Koenig wrote:
> <r.....@gmail.com> schrieb:
>> On Thursday, April 23, 2020 at 11:50:49 AM UTC+10, John Levine wrote:
>>> In article <28db727b-c583-4da........@googlegroups.com>,
>>> <r......@gmail.com> wrote:
>>>
>>> [ about the 360's floating point ]
>>>>
>>>> That's right, up to around 10**75.
>>>>
>>>> It also speeded up pre-normalisation and post-normalization;
>>>> at most, up to 5 shifts instead of 23 shifts otherwise.
>>>> It was a trade-off.
>>>
>>> No question it was fast, but the wobbling precision and truncation were bad news.
>>
>>>> > This played hob with numerical approximations by iteration, as when you got
>>>> > close to the final result, the random jumping of precision was bigger than
>>>> > the epsilon of the approximation.
>>>>
>>>> It worked fine.
>>>
>>> It was certainly possible to work around it with enough effort.
>>
>> No "work-around" was required. It worked fine as it was.
>
> Did you ever implement linear equation solvers?

Of course. And I have done experiments with row and/or column
interchanges.

> If so, up to how
> many equations did you manage to solve?

>>> IBM shipped
>>> high quality numerical libraries that got very good results.
>>
>> There was a large library for both FORTRAN and PL/I.
>
> I used NAG, but that was much later.
Re: Micros as number crunchers [message #393739 is a reply to message #393679] Thu, 23 April 2020 06:29 Go to previous messageGo to next message
Anonymous
Karma:
Originally posted by: Kerr-Mudd,John

On Tue, 21 Apr 2020 21:03:06 GMT, Jorgen Grahn
<grahn+nntp@snipabacken.se> wrote:

> On Tue, 2020-04-21, Dan Espen wrote:
>> Peter Flass <peter_flass@yahoo.com> writes:
>>
>>> Jorgen Grahn <grahn+nntp@snipabacken.se> wrote:
> ...
>
>>>> BTW, I had a strange experience at a previous (but recent)
>>>> workplace. I had to print some data in hex, and naturally chose
>>>> lower case hex, e.g. 0x0f1e. The others however found that odd:
>>>> they wanted me to change it to 0x0F1E. I thought it was a joke at
>>>> first, but they insisted; they really found the lowercase form odd.
>>>> A Windows thing, perhaps?
>>>
>>> Nope, I’m an old mainframe guy and I find it odd. I just got used
>>> to looking at a hex dump with upper-case A-F. Besides, I think the
>>> upper-case is more readable here, since the letters are larger and
>>> more distinct vs. lower-case.
>>
>> Yep, mainframe thing. It was A-F for decades.
>> Using lower case just doesn't look right.
>
> However, my coworkers were much too young for mainframes, so uppercase
> is popular somewhere else too.
>
> /Jorgen
>

It is to hopefully keep at bay (albeit rare) confusing of label & hex
values; FIELD v F1E1D. DEADBEEF was always popular amongst some nerdy
types.


--
Bah, and indeed, Humbug.
Re: Micros as number crunchers [message #393740 is a reply to message #393731] Thu, 23 April 2020 13:54 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Charlie Gibbs <cgibbs@kltpzyxm.invalid> wrote:
> On 2020-04-23, Peter Flass <peter_flass@yahoo.com> wrote:
>
>> Quadibloc <jsavard@ecn.ab.ca> wrote:
>>
>>> On Tuesday, April 21, 2020 at 2:05:42 PM UTC-6, Jorgen Grahn wrote:
>>>
>>>> BTW, I had a strange experience at a previous (but recent) workplace.
>>>> I had to print some data in hex, and naturally chose lower case hex,
>>>> e.g. 0x0f1e. The others however found that odd: they wanted me to
>>>> change it to 0x0F1E. I thought it was a joke at first, but they
>>>> insisted; they really found the lowercase form odd. A Windows thing,
>>>> perhaps?
>>>
>>> As others have noted, Windows isn't the culprit.
>>>
>>> The current standard for hexadecimal, with the letters from A through
>>> F as the additional digits, originated with the IBM System/360, and
>>> it consistently used only the upper-case letters, both on the computer
>>> and in documentation.
>>>
>>> On the other hand, much later, Unix and C used lower-case hexadecimal,
>>> and Windows is in the modern camp with those.
>>>
>>> Before the System/360 came along, a few other computers used hexadecimal
>>> instead of octal, but they often used a *different* set of letters for
>>> the extra digits.
>>>
>>> Here are the examples
>>>
>>> Bendix G-15, SWAC u v w x y z
>>> Monrobot XI S T U V W X
>>> Datamatic D-1000 b c d e f g
>>> Elbit 100 B C D E F G
>>> LGP-30 f g j k q w
>>> ILLIAC k s n j f l
>>> Pacific Data Systems 1020 L C A S M D
>>>
>>> that I've listed on my web page at
>>> http://www.quadibloc.com/comp/cp02.htm
>>
>> Wow, obviously not mnemonic, maybe some hardware thing? How about T E V R F
>> N for Ten Eleven twelVe thIRteen Fourteen and fifteeN?
>
> In grade 8 math we played with several different bases, all but one of
> which were less than 10. For base twelve, however, we used T (ten) and
> E (eleven) for the two topmost digits.
>
> Five years later I was introduced to hexadecimal, IBM style (A-F).
> Once, just for kicks, I performed long division in hex. It's one
> of those things that you do just once.
>

Or maybe not at all. At one point I was thinking about memorizing
multiplication tables in hex, but fortunately never followed thru on the
thought.

--
Pete
Re: Micros as number crunchers [message #393741 is a reply to message #393734] Thu, 23 April 2020 13:54 Go to previous messageGo to next message
Peter Flass is currently offline  Peter Flass
Messages: 8375
Registered: December 2011
Karma: 0
Senior Member
Thomas Koenig <tkoenig@netcologne.de> wrote:
> robin.vowels@gmail.com <robin.vowels@gmail.com> schrieb:
>> On Thursday, April 23, 2020 at 7:53:00 AM UTC+10, Jon Elson wrote:
>>> Thomas Koenig wrote:
>>
>>>> There was a good reason why the old IBM scientific machines had
>>>> 36 bit floating point, but that was sacrificed on the altar of
>>>> the all-round system, the 360.
>>>
>>> But, they botched it even worse on the 360. Single precision float had a
>>> 24-bit mantissa, but they normalized in 4-bit steps. So, any particular
>>> result could have up to 3 most significant zeroes in the mantissa,
>>> squeezing out up to 3 bits of precision.
>>
>> They didn\t "squeeze out" 3 bits of precision.
>> All that was guaranteed was 21 bits of mantissa.
>
> Which pretty much shortchanged the customers.
>
> 21 bits of precision out of a 32 bit float is far worse than could
> have been done, especially for things like linear algebra.
>
>>> This allowed the exponent to
>>> cover an 8X larger range, as it was a power of 16, not power of 2.
>>
>> That's right, up to around 10**75.
>>
>> It also speeded up pre-normalisation and post-normalization;
>> at most, up to 5 shifts instead of 23 shifts otherwise.
>> It was a trade-off.
>
> At the expense of the usability of the four-byte real number.
>
> Having to use double precision for anything remotely useful, with
> the much higher cost in memory and computation speed, is not really
> a good thing.
>
>>
>>> This played hob with numerical approximations by iteration, as when you got
>>> close to the final result, the random jumping of precision was bigger than
>>> the epsilon of the approximation.
>>
>> It worked fine.
>
> I fought it, eventually giving in and using double precision only.
>

The 360/44 had a console switch for long vs. short FP. I’m not sure how it
worked. You had to re-ipl to change the setting.

--
Pete
Re: Micros as number crunchers [message #393744 is a reply to message #393734] Thu, 23 April 2020 18:32 Go to previous messageGo to next message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 2:17:26 AM UTC-6, Thomas Koenig wrote:
> robin.vowels@gmail.com <robin.vowels@gmail.com> schrieb:

>> They didn\t "squeeze out" 3 bits of precision.
>> All that was guaranteed was 21 bits of mantissa.

> Which pretty much shortchanged the customers.

> 21 bits of precision out of a 32 bit float is far worse than could
> have been done, especially for things like linear algebra.

Remember that a lot of the System/360 processors didn't have special hardware
for floating-point, only microcode for it. If the mantissa had been shifted a
bit at a time, instead of half a byte at a time, floating-point arithmetic would
have been much slower on those low-end models.

John Savard
Re: Micros as number crunchers [message #393745 is a reply to message #393741] Thu, 23 April 2020 18:35 Go to previous messageGo to previous message
Quadibloc is currently offline  Quadibloc
Messages: 4399
Registered: June 2012
Karma: 0
Senior Member
On Thursday, April 23, 2020 at 11:54:20 AM UTC-6, Peter Flass wrote:

> The 360/44 had a console switch for long vs. short FP. I’m not sure how it
> worked. You had to re-ipl to change the setting.

What it had was a knob - you could set it so that the double-precision
instructions only worked as if double-precision floats were 60, 56, 52, 48, 44,
40, or 36 bits long instead of 64 bits long; so your programs that used double
precision could run as fast as possible, only using as much precision as they
needed but no more.

John Savard
Pages (4): [ «    1  2  3  4    »]  Switch to threaded view of this topic Create a new topic Submit Reply
Previous Topic: Was there ever a complete CPL compiler?
Next Topic: Re: SEL 810A computer
Goto Forum:
  

-=] Back to Top [=-
[ Syndicate this forum (XML) ] [ RSS ] [ PDF ]

Current Time: Thu Mar 28 19:26:15 EDT 2024

Total time taken to generate the page: 0.02885 seconds