What's new with the new multi-context processor patent ?
http://www.freepatentsonline.com/5872985.html
To post a message, send it to: f...
To unsubscribe, send a blank message to: f...
Multi-context processor
Started by ●November 6, 2006
Reply by ●November 6, 20062006-11-06
Rob Finch wrote:
> What's new with the new multi-context processor patent ?
>
> http://www.freepatentsonline.com/5872985.html
It's a US patent; it doesn't have to have anything new in it. This is
the patent office that has issued 20-odd patents on perpetual motion
machines.
PD
To post a message, send it to: f...
To unsubscribe, send a blank message to: f...
> What's new with the new multi-context processor patent ?
>
> http://www.freepatentsonline.com/5872985.html
It's a US patent; it doesn't have to have anything new in it. This is
the patent office that has issued 20-odd patents on perpetual motion
machines.
PD
To post a message, send it to: f...
To unsubscribe, send a blank message to: f...
Reply by ●November 9, 20062006-11-09
--- In f..., Paul Davis wrote:
>
> Rob Finch wrote:
> > What's new with the new multi-context processor patent ?
> >
> > http://www.freepatentsonline.com/5872985.html
>
> It's a US patent; it doesn't have to have anything new in it. This is
> the patent office that has issued 20-odd patents on perpetual motion
> machines.
>
> PD
So who else has a CPU that runs multiple contexts (programs) through
the pipeline at the same time?
At least that's what it sounded like it was doing... whenever one
context stalls the other can run to keep the CPU doing something all
the time.
>
> Rob Finch wrote:
> > What's new with the new multi-context processor patent ?
> >
> > http://www.freepatentsonline.com/5872985.html
>
> It's a US patent; it doesn't have to have anything new in it. This is
> the patent office that has issued 20-odd patents on perpetual motion
> machines.
>
> PD
So who else has a CPU that runs multiple contexts (programs) through
the pipeline at the same time?
At least that's what it sounded like it was doing... whenever one
context stalls the other can run to keep the CPU doing something all
the time.
Reply by ●November 9, 20062006-11-09
Does he say he has that?
Or is he proposing?
Its sounds relatively abstract
but if he already implemented that - he's all made...
My idea is more along the programmers model of a cubic (6 interfaces to
every neighbouring program step)
multiprocessor, where many processors can execute on the cubespace running
datastreeams through the interfaces
what I'm suggesting is a way of looking the grafts in parallel linear memory
bitrange where any number of but never two neighbouring virtual cubes access
their linear memory in and out 'bitfaces'
reading them and writing them back after executing a number of cycles on
them
The program is the fusemap of the fpga that loans its 'processingtime' to
the virtual cube
The goal is a architecture fit for Finite Elements Modeling
lets look into implementing this folks!
On 11/8/06, James Diffendaffer wrote:
>
> --- In f..., Paul Davis wrote:
> >
> > Rob Finch wrote:
> > > What's new with the new multi-context processor patent ?
> > >
> > > http://www.freepatentsonline.com/5872985.html
> >
> > It's a US patent; it doesn't have to have anything new in it. This is
> > the patent office that has issued 20-odd patents on perpetual motion
> > machines.
> >
> > PD
>
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
> To post a message, send it to: f...
> To unsubscribe, send a blank message to:
> f...
> Yahoo! Groups Links
>
--
-----
Tobias Gogolin
cel. (646) 124 32 82
skype: moontogo
messenger: u...@hotmail.com
Or is he proposing?
Its sounds relatively abstract
but if he already implemented that - he's all made...
My idea is more along the programmers model of a cubic (6 interfaces to
every neighbouring program step)
multiprocessor, where many processors can execute on the cubespace running
datastreeams through the interfaces
what I'm suggesting is a way of looking the grafts in parallel linear memory
bitrange where any number of but never two neighbouring virtual cubes access
their linear memory in and out 'bitfaces'
reading them and writing them back after executing a number of cycles on
them
The program is the fusemap of the fpga that loans its 'processingtime' to
the virtual cube
The goal is a architecture fit for Finite Elements Modeling
lets look into implementing this folks!
On 11/8/06, James Diffendaffer wrote:
>
> --- In f..., Paul Davis wrote:
> >
> > Rob Finch wrote:
> > > What's new with the new multi-context processor patent ?
> > >
> > > http://www.freepatentsonline.com/5872985.html
> >
> > It's a US patent; it doesn't have to have anything new in it. This is
> > the patent office that has issued 20-odd patents on perpetual motion
> > machines.
> >
> > PD
>
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
> To post a message, send it to: f...
> To unsubscribe, send a blank message to:
> f...
> Yahoo! Groups Links
>
--
-----
Tobias Gogolin
cel. (646) 124 32 82
skype: moontogo
messenger: u...@hotmail.com
Reply by ●November 9, 20062006-11-09
James Diffendaffer wrote:
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
My life is too short to work out exactly what he was claiming, but it
does appear that the patent covers some form of multithreading (TLP,
thread-level parallelism). IBM started working on TLP in about 1968. H&P
(3rd edition) gives a brief description of the IBM RS64 III/Pulsar as an
example of TLP. This seems to date to about 1999, but H&P claim that the
transistorised TX-2 (1959) could also support multithreading. Intel has
supported multithreading since the Pentium 4, based on an earlier DEC
Alpha. Ask on comp.arch for a more definitive answer.
My 5-minute scan of the patent made me suspect that it was attempting to
claim something specific about the meaning of a 'context', because it
must have been obvious in 1995 that TLP wasn't new. But, as I said, it's
a US patent, so it hardly needs to reflect the state of the art.
> So who else has a CPU that runs multiple contexts (programs) through
> the pipeline at the same time?
> At least that's what it sounded like it was doing... whenever one
> context stalls the other can run to keep the CPU doing something all
> the time.
My life is too short to work out exactly what he was claiming, but it
does appear that the patent covers some form of multithreading (TLP,
thread-level parallelism). IBM started working on TLP in about 1968. H&P
(3rd edition) gives a brief description of the IBM RS64 III/Pulsar as an
example of TLP. This seems to date to about 1999, but H&P claim that the
transistorised TX-2 (1959) could also support multithreading. Intel has
supported multithreading since the Pentium 4, based on an earlier DEC
Alpha. Ask on comp.arch for a more definitive answer.
My 5-minute scan of the patent made me suspect that it was attempting to
claim something specific about the meaning of a 'context', because it
must have been obvious in 1995 that TLP wasn't new. But, as I said, it's
a US patent, so it hardly needs to reflect the state of the art.
Reply by ●November 9, 20062006-11-09
----- Original Message -----
From: "Tobias Gogolin"
To:
Sent: Thursday, November 09, 2006 8:57 AM
Subject: Re: [fpga-cpu] Re: Multi-context processor
> Does he say he has that?
> Or is he proposing?
> Its sounds relatively abstract
> but if he already implemented that - he's all made...
>
> My idea is more along the programmers model of a cubic (6 interfaces to
> every neighbouring program step)
> multiprocessor, where many processors can execute on the cubespace running
> datastreeams through the interfaces
> what I'm suggesting is a way of looking the grafts in parallel linear
> memory
> bitrange where any number of but never two neighbouring virtual cubes
> access
> their linear memory in and out 'bitfaces'
> reading them and writing them back after executing a number of cycles on
> them
> The program is the fusemap of the fpga that loans its 'processingtime' to
> the virtual cube
> The goal is a architecture fit for Finite Elements Modeling
>
> lets look into implementing this folks!
I was developing transputer-based systems 25 years ago, and was thinking of
designing a very compact hypercube, using chip-on-board technology, which
could be extended to any arbitrary dimensionality. I helped someone port
some FEM software to one of my systems, running on a single transputer. I
don't know if he ever parallelised it.
Leon
--
Leon Heller, G1HSM
Suzuki SV1000S motorcycle
l...@bulldoghome.com
http://webspace.webring.com/people/jl/leon_heller/
From: "Tobias Gogolin"
To:
Sent: Thursday, November 09, 2006 8:57 AM
Subject: Re: [fpga-cpu] Re: Multi-context processor
> Does he say he has that?
> Or is he proposing?
> Its sounds relatively abstract
> but if he already implemented that - he's all made...
>
> My idea is more along the programmers model of a cubic (6 interfaces to
> every neighbouring program step)
> multiprocessor, where many processors can execute on the cubespace running
> datastreeams through the interfaces
> what I'm suggesting is a way of looking the grafts in parallel linear
> memory
> bitrange where any number of but never two neighbouring virtual cubes
> access
> their linear memory in and out 'bitfaces'
> reading them and writing them back after executing a number of cycles on
> them
> The program is the fusemap of the fpga that loans its 'processingtime' to
> the virtual cube
> The goal is a architecture fit for Finite Elements Modeling
>
> lets look into implementing this folks!
I was developing transputer-based systems 25 years ago, and was thinking of
designing a very compact hypercube, using chip-on-board technology, which
could be extended to any arbitrary dimensionality. I helped someone port
some FEM software to one of my systems, running on a single transputer. I
don't know if he ever parallelised it.
Leon
--
Leon Heller, G1HSM
Suzuki SV1000S motorcycle
l...@bulldoghome.com
http://webspace.webring.com/people/jl/leon_heller/
Reply by ●November 9, 20062006-11-09
Paul Davis wrote:
> but H&P claim that the
> transistorised TX-2 (1959) could also support multithreading.
The TX-2 hardware does support multiple threads (called "sequences"),
but not simultaneity. There is a priority system to arbitrate for use
of the processor.
The PPUs of the CDC 6600 were similar, in that a single physical
processor serviced ten threads in round-robin fashion (known as
a barrel processor).
More recent examples are the Ubicom IP3023 and IP5160
microprocessors, which support multiple threads with provision
for fixed time slices for "hard real time" threads, and round
robin with two priority levels for the remaining threads.
(Disclaimer: I am employed by Ubicom.)
Simultaneous Multi Threading (SMT) has only been offered on
relatively high-end microprocessors, including the DEC Alpha 21264
(unreleased), Intel Pentium 4, and IBM POWER5.
> but H&P claim that the
> transistorised TX-2 (1959) could also support multithreading.
The TX-2 hardware does support multiple threads (called "sequences"),
but not simultaneity. There is a priority system to arbitrate for use
of the processor.
The PPUs of the CDC 6600 were similar, in that a single physical
processor serviced ten threads in round-robin fashion (known as
a barrel processor).
More recent examples are the Ubicom IP3023 and IP5160
microprocessors, which support multiple threads with provision
for fixed time slices for "hard real time" threads, and round
robin with two priority levels for the remaining threads.
(Disclaimer: I am employed by Ubicom.)
Simultaneous Multi Threading (SMT) has only been offered on
relatively high-end microprocessors, including the DEC Alpha 21264
(unreleased), Intel Pentium 4, and IBM POWER5.
Reply by ●November 9, 20062006-11-09
I wrote:
> Simultaneous Multi Threading (SMT) has only been offered on
> relatively high-end microprocessors, including the DEC Alpha 21264
> (unreleased),
That's a typo. It was to be the 21464. The 21264 was released
but does not have SMT.
> Simultaneous Multi Threading (SMT) has only been offered on
> relatively high-end microprocessors, including the DEC Alpha 21264
> (unreleased),
That's a typo. It was to be the 21464. The 21264 was released
but does not have SMT.
Reply by ●November 10, 20062006-11-10
Eric Smith wrote:
> (Disclaimer: I am employed by Ubicom.)
You should fix your MX records on ubicom.com - www.ubicom.com is Ok.
> (Disclaimer: I am employed by Ubicom.)
You should fix your MX records on ubicom.com - www.ubicom.com is Ok.
Reply by ●November 10, 20062006-11-10
Eric Smith wrote:
> The TX-2 hardware does support multiple threads (called "sequences"),
> but not simultaneity. There is a priority system to arbitrate for use
> of the processor.
>
> The PPUs of the CDC 6600 were similar, in that a single physical
> processor serviced ten threads in round-robin fashion (known as
> a barrel processor).
>
> More recent examples are the Ubicom IP3023 and IP5160
> microprocessors, which support multiple threads with provision
> for fixed time slices for "hard real time" threads, and round
> robin with two priority levels for the remaining threads.
> (Disclaimer: I am employed by Ubicom.)
That reminds me of another example - the Transputer (1982/3?), which had
a more sophisticated (of course, it was nearly 20 years later)
scheduler. This carried on executing a thread until it blocked on an I/O
operation. Actually, perhaps it was less sophisticated - my recollection
is that it was difficult to write code because there was no pre-emptive
scheduling, and you had to manually put in instructions to force a swap.
> The TX-2 hardware does support multiple threads (called "sequences"),
> but not simultaneity. There is a priority system to arbitrate for use
> of the processor.
>
> The PPUs of the CDC 6600 were similar, in that a single physical
> processor serviced ten threads in round-robin fashion (known as
> a barrel processor).
>
> More recent examples are the Ubicom IP3023 and IP5160
> microprocessors, which support multiple threads with provision
> for fixed time slices for "hard real time" threads, and round
> robin with two priority levels for the remaining threads.
> (Disclaimer: I am employed by Ubicom.)
That reminds me of another example - the Transputer (1982/3?), which had
a more sophisticated (of course, it was nearly 20 years later)
scheduler. This carried on executing a thread until it blocked on an I/O
operation. Actually, perhaps it was less sophisticated - my recollection
is that it was difficult to write code because there was no pre-emptive
scheduling, and you had to manually put in instructions to force a swap.