Prev: Realistic colors for monitors ?
Next: CFP Applied Computing 2010: submissions until 28 May 2010
From: Stephen Fuld on 13 Apr 2010 02:51
On 4/12/2010 6:36 PM, nedbrek wrote:
> Hello all,
>
> "Quadibloc"<jsavard(a)ecn.ab.ca> wrote in message
> news:e80b1c12-e74e-4689-b1e2-c045a1847071(a)35g2000yqm.googlegroups.com...
> [snip, a lot of crazy stuff]
>
> I am truly impressed. Reminds me of the IA-128 file I used to keep at work
> (combining all the worst parts of i860, IA64, and more bad stuff).
>
>> a mode where, when fetching from a part of memory used for data and not
>> instructions, it fills only 9 of those slots in each line of the L2 cache,
>> so
>> that when data goes from L2 cache to L1 cache, a maze of wires puts 36
>> contiguous bits of data into every 64 bits of the L1 cache, so the
>> computer can act as if it has a 36 bit word)...
>
> Is that some sort of S/360 compatibility thing?

No, S/360 had 32 bit words. But several systems used 36 bit words.
These included the Dec Systems 10 and 20, the Univac 1100 series, some
Honeywell models and I believe some others. It worked well when storage
was very expensive and systems used 6 bit characters.


--
- Stephen Fuld
(e-mail address disguised to prevent spam)
From: Quadibloc on 13 Apr 2010 14:38
On Apr 12, 7:36 pm, "nedbrek" <nedb...(a)yahoo.com> wrote:

> I am truly impressed.  Reminds me of the IA-128 file I used to keep at work
> (combining all the worst parts of i860, IA64, and more bad stuff).

Yes... although I am trying to combine _good_ stuff... but from a
longer list of historic architectures. Although the "cosequence
counter" of the Honeywell 800 - a second program counter, apparently
done so that context switching overhead could be avoided while having,
in effect, two processes running concurrently (I think it was to
optimize sort routines) - is one of the more bizarre things that I
thought worthy of throwing in to the mix.

John Savard
From: Quadibloc on 13 Apr 2010 14:44
On Apr 13, 12:51 am, Stephen Fuld <SF...(a)alumni.cmu.edu.invalid>
wrote:
> On 4/12/2010 6:36 PM, nedbrek wrote:
> > "Quadibloc"<jsav...(a)ecn.ab.ca>  wrote in message
> >news:e80b1c12-e74e-4689-b1e2-c045a1847071(a)35g2000yqm.googlegroups.com...

> >> a mode where, when fetching from a part of memory used for data and not
> >> instructions, it fills only 9 of those slots in each line of the L2 cache,
> >> so
> >> that when data goes from L2 cache to L1 cache, a maze of wires puts 36
> >> contiguous bits of data into every 64 bits of the L1 cache, so the
> >> computer can act as if it has a 36 bit word)...
>
> > Is that some sort of S/360 compatibility thing?
>
> No, S/360 had 32 bit words.  But several systems used 36 bit words.
> These included the Dec Systems 10 and 20, the Univac 1100 series, some
> Honeywell models and I believe some others.  It worked well when storage
> was very expensive and systems used 6 bit characters.

Yes; storage was expensive, and bit addressing was not used (this was
the feature that led to STRETCH using a 64-bit word; it is something
not used much on computers) so they designed the computer around the
character set in use.

And the old punched-card data processing machines used only uppercase
letters - and a minimal handful of punctuation marks, so they often
used only a 48-character set - so six bits was felt to be plenty.

The IBM 7090 (and its relatives, from the IBM 704 forwards), the
popular binary scientific predecessor of the System/360, used 36-bit
words as well, which may be why that particular word length was almost
considered a standard.

John Savard
From: "Andy "Krazy" Glew" on 14 Apr 2010 00:07
On 4/13/2010 11:38 AM, Quadibloc wrote:
> On Apr 12, 7:36 pm, "nedbrek"<nedb...(a)yahoo.com> wrote:
>
>> I am truly impressed. Reminds me of the IA-128 file I used to keep at work
>> (combining all the worst parts of i860, IA64, and more bad stuff).
>
> Yes... although I am trying to combine _good_ stuff... but from a
> longer list of historic architectures. Although the "cosequence
> counter" of the Honeywell 800 - a second program counter, apparently
> done so that context switching overhead could be avoided while having,
> in effect, two processes running concurrently (I think it was to
> optimize sort routines) - is one of the more bizarre things that I
> thought worthy of throwing in to the mix.
>
> John Savard

Don't bother with a cosequence counter.

Just enable swapping the current instruction pointer / program counter with one held in a register.

Or swap an entire register set, including IPs, if you really want.
From: Quadibloc on 14 Apr 2010 07:06
On Apr 13, 10:07 pm, "Andy \"Krazy\" Glew" <ag-n...(a)patten-glew.net>
wrote:

> Don't bother with a cosequence counter.
>
> Just enable swapping the current instruction pointer / program counter with one held in a register.
>
> Or swap an entire register set, including IPs, if you really want.

Basically, the Honeywell 800 managed by having a large set of
registers, so that the two pseudo-concurrent processes could use
different sets of registers.

On the Honeywell 800, each instruction contained one bit to indicate
which program counter would be used for fetching the next instruction,
so the intention was that even the overhead of moving the program
counter anywhere was to be avoided. This is why I think it was
intended for highly-optimized sort routines; extremely low overhead
for concurrency of two routines especially written to be concurrent.
Today, of course, multi-threading allows concurrency without overhead,
and also at the cost of additional hardware - but without any special
constraints on the threads.

John Savard
First  |  Prev  |  Next  |  Last
Pages: 1 2 3
Prev: Realistic colors for monitors ?
Next: CFP Applied Computing 2010: submissions until 28 May 2010