[Qemu-devel] VLIW?

[Qemu-devel] VLIW?

[Gibbons, Scott]

[-- Attachment #1.1: Type: text/plain, Size: 358 bytes --]

Has anyone done a port of QEMU to a VLIW architecture?  I'm interested in seeing what was done.

Thanks,
--Scott

-----------------------------------------------------------
Qualcomm Inc. / Hexagon Tools
Austin, TX
sgibbons@qualcomm.com<mailto:dmoore@qualcomm.com>
Office: 512-623-3831
Cell: 469-450-8390
[cid:image001.gif@01CB0C78.FB99A370]



[-- Attachment #1.2: Type: text/html, Size: 3723 bytes --]

[-- Attachment #2: image001.gif --]
[-- Type: image/gif, Size: 1193 bytes --]

Re: [Qemu-devel] VLIW?

[Aurelien Jarno]

On Tue, Jun 15, 2010 at 08:53:26AM -0700, Gibbons, Scott wrote:
> Has anyone done a port of QEMU to a VLIW architecture?  I'm interested in seeing what was done.
> 

The git version of QEMU is working on IA64, which is an EPIC CPU, but
can be considered as certain kind of VLIW CPU.

-- 
Aurelien Jarno	                        GPG: 1024D/F1BCDB73
aurelien@aurel32.net                 http://www.aurel32.net

Re: [Qemu-devel] VLIW?

[Richard Henderson]

On 06/15/2010 08:53 AM, Gibbons, Scott wrote:
> Has anyone done a port of QEMU to a VLIW architecture?  I’m interested
> in seeing what was done.

Do you mean as guest or host?  I presume guest.

There's not such a port in the main repository; I don't know
what might have been done privately.

It'll be a more difficult job if you have an open pipeline, but
even then I should think it could be done.  It really depends on
the exact specification of your cpu.

For instance, with a closed pipeline, I think all you would need
to track during translation are the output temporaries.  You would
translate each member instruction sequentially, but delay writeback
to the architectual register until the end of the vliw packet.

With an open pipeline, I imagine that you would model each exposed
architectural feature.  For instance, if a load insn places its
result onto a bus in the cycle following the issue of the load,
then you could model the bus with a TCG register and have the
translator be responsible for issuing moves between the TCG 
registers during appropriate cycles.

I imagine the difficulty increases (but not intractably) if you
want the translator to catch and signal user coding errors in the
vliw assembly.  Though usually that's a job that can be performed
statically by the assembler...


r~

RE: [Qemu-devel] VLIW?

[Gibbons, Scott]

Yes, as a guest.

Thanks for the helpful suggestions.  We have a closed pipeline and code errors are caught by the assembler.  Delaying writeback is most likely what I'll be doing.

Another question I have is how to handle this multithreaded architecture.  This seems to be extraordinarily difficult as a dynamic translation problem and I'll probably defer it to later.  But, if anyone has any suggestions, I'd be glad to hear them.

Thanks,
--Scott

-----------------------------------------------------------
Qualcomm Inc. / Hexagon Tools
Austin, TX




-----Original Message-----
From: Richard Henderson [mailto:rth7680@gmail.com] On Behalf Of Richard Henderson
Sent: Wednesday, June 16, 2010 12:41 PM
To: Gibbons, Scott
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] VLIW?

On 06/15/2010 08:53 AM, Gibbons, Scott wrote:
> Has anyone done a port of QEMU to a VLIW architecture?  I'm interested
> in seeing what was done.

Do you mean as guest or host?  I presume guest.

There's not such a port in the main repository; I don't know
what might have been done privately.

It'll be a more difficult job if you have an open pipeline, but
even then I should think it could be done.  It really depends on
the exact specification of your cpu.

For instance, with a closed pipeline, I think all you would need
to track during translation are the output temporaries.  You would
translate each member instruction sequentially, but delay writeback
to the architectual register until the end of the vliw packet.

With an open pipeline, I imagine that you would model each exposed
architectural feature.  For instance, if a load insn places its
result onto a bus in the cycle following the issue of the load,
then you could model the bus with a TCG register and have the
translator be responsible for issuing moves between the TCG 
registers during appropriate cycles.

I imagine the difficulty increases (but not intractably) if you
want the translator to catch and signal user coding errors in the
vliw assembly.  Though usually that's a job that can be performed
statically by the assembler...


r~

Re: [Qemu-devel] VLIW?

[Richard Henderson]

On 06/17/2010 08:12 AM, Gibbons, Scott wrote:
> Another question I have is how to handle this multithreaded
> architecture.  This seems to be extraordinarily difficult as a
> dynamic translation problem and I'll probably defer it to later.
> But, if anyone has any suggestions, I'd be glad to hear them.

How is your threading different from other SMP systems?

In system mode, QEMU TCG is single-threaded and models SMP via
cooperative switching in between TCG translation blocks.  It's
not ideal, but it does solve quite a number of problems and is
at least functional.


r~

RE: [Qemu-devel] VLIW?

[Gibbons, Scott]

My architecture is an Interleaved Multithreading VLIW architecture.  One bundle (packet) executes per processor cycle, rotating between threads (i.e., thread 0 executes at time 0, thread 1 executes at time 1, then thread 0 executes at time 2, etc.).  Each thread has its own context (including a program counter).  I'm not sure what kind of performance I would get in translating a single bundle at a time (or maybe I'm misunderstanding).

I think I'll get basic single-thread operation working first, then attempt multithreading when I have a spare month or so.

Thanks,
--Scott

-----------------------------------------------------------
Qualcomm Inc. / Hexagon Tools
Austin, TX
sgibbons@qualcomm.com
Office: 512-623-3831
Cell: 469-450-8390




-----Original Message-----
From: Richard Henderson [mailto:rth7680@gmail.com] On Behalf Of Richard Henderson
Sent: Thursday, June 17, 2010 11:03 AM
To: Gibbons, Scott
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] VLIW?

On 06/17/2010 08:12 AM, Gibbons, Scott wrote:
> Another question I have is how to handle this multithreaded
> architecture.  This seems to be extraordinarily difficult as a
> dynamic translation problem and I'll probably defer it to later.
> But, if anyone has any suggestions, I'd be glad to hear them.

How is your threading different from other SMP systems?

In system mode, QEMU TCG is single-threaded and models SMP via
cooperative switching in between TCG translation blocks.  It's
not ideal, but it does solve quite a number of problems and is
at least functional.


r~

Re: [Qemu-devel] VLIW?

[Richard Henderson]

On 06/17/2010 11:05 AM, Gibbons, Scott wrote:
> My architecture is an Interleaved Multithreading VLIW architecture.
> One bundle (packet) executes per processor cycle, rotating between
> threads (i.e., thread 0 executes at time 0, thread 1 executes at time
> 1, then thread 0 executes at time 2, etc.).  Each thread has its own
> context (including a program counter).

Ah, I see.  And presumably this knowledge of synchronicity is something
that can be leveraged by the programmer for specific tasks?  Or does 
the closed pipeline mean that you have unpredictable delays that can
stall the pipeline, which can then throw off the thread lock-step?

> I'm not sure what kind of
> performance I would get in translating a single bundle at a time (or
> maybe I'm misunderstanding).

"Poor" might be a word to describe it.

> I think I'll get basic single-thread operation working first, then
> attempt multithreading when I have a spare month or so.

Good plan.


r~

Re: [Qemu-devel] VLIW?

[Jamie Lokier]

Gibbons, Scott wrote:
> My architecture is an Interleaved Multithreading VLIW architecture.  One bundle (packet) executes per processor cycle, rotating between threads (i.e., thread 0 executes at time 0, thread 1 executes at time 1, then thread 0 executes at time 2, etc.).  Each thread has its own context (including a program counter).  I'm not sure what kind of performance I would get in translating a single bundle at a time (or maybe I'm misunderstanding).
> 
> I think I'll get basic single-thread operation working first, then attempt multithreading when I have a spare month or so.

I know of another CPU architecture that has fine-grained hardware
threads and has working qemu emulation at a useful performance for
debugging kernels, but it's not public as far as I know, and I don't
know if it's ok to name it.  I don't think it's VLIW, only that it has
lots of hardware threads and a working qemu model.

-- Jamie

[Qemu-devel] VLIW?

[Gibbons, Scott]

[-- Attachment #1: Type: text/plain, Size: 188 bytes --]

Not sure if this got through since I had stuff in my signature.

Has anyone done a port of QEMU to a VLIW architecture?  I'm interested in seeing what was done.

Thanks,
--Scott



[-- Attachment #2: Type: text/html, Size: 2477 bytes --]