Prev: Realistic colors for monitors ?
Next: CFP Applied Computing 2010: submissions until 28 May 2010
From: "Andy "Krazy" Glew" on 14 Apr 2010 23:41
On 4/14/2010 4:06 AM, Quadibloc wrote:
> 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.

I still like real coroutine threads - and I have used them pretty damned recently. One Intel's most used performance
simulators is coroutine threaded - NOT simultaneous threaded. Coroutine threads are really useful because they are
deterministic, and easy to debug; but especially because they mean that you can leave a whole slew of state as stack
local variables, rather than having to put them in a struct somewhere.

There were/are way more than 2 threads in this coroutine system. They are also dynamic: the currently running thread
does not know what thread will run next.



From: Quadibloc on 15 Apr 2010 09:23
Although at least two pages (those two having an indication placed on
them) have not yet been updated for the change (not counting many
pages, of course, that did not need to be changed), I have uploaded
the revisions to the page now which show the architecture as modified
to have one instruction mode only, this mode allowing efficient length
decoding.

John Savard
From: Quadibloc on 17 Apr 2010 00:39
On Apr 15, 7:23 am, Quadibloc <jsav...(a)ecn.ab.ca> wrote:
> Although at least two pages (those two having an indication placed on
> them) have not yet been updated for the change (not counting many
> pages, of course, that did not need to be changed), I have uploaded
> the revisions to the page now which show the architecture as modified
> to have one instruction mode only, this mode allowing efficient length
> decoding.

I have made further revisions to what had already been posted, so as
to make the ordering of fields in some instructions more consistent
with general practise, and to improve the handling of instructions
involving the supplementary registers (which also allowed two-address
long vector instructions to be shortened by 16 bits), in addition to
converting the two remaining pages.

Thus, the description of the revised version of the architecture
appears now to be complete.

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