FPGA implementation of ARM and IA32 ISA

[khoa nguyen]

I'd like to support the ARM and IA32 ISA on an FPGA. At the moment Im unsure
if I can do this. So what I thought is that if only I have some small clean
test bench of both ISA's, then I could start supporting those small set of
instructions. Later on I would add in the rest.

Im wondering if there's anyone that happens to have some small clean test
benchs or even applications, then could you forward them to me.

thanks heaps.

 

[john jakson]

"khoa nguyen" <jeffn@ihug.com.au> wrote in message news:<c1p5k1$5sm$1@lust.ihug.co.nz>...

I'd like to support the ARM and IA32 ISA on an FPGA. At the moment Im unsure
if I can do this. So what I thought is that if only I have some small clean
test bench of both ISA's, then I could start supporting those small set of
instructions. Later on I would add in the rest.

Im wondering if there's anyone that happens to have some small clean test
benchs or even applications, then could you forward them to me.

thanks heaps.

About the time when Pentium 100 was introduced, there were a number of
authers that wrote books on optimising x86 code to run as fast as
possible. I have a few of these but in the office so I can't recall
names v books.

The jist of one of these " ... Inner Loops ..." was that if you
limited yourself to certain ops, you could get x86 to perform very
well indeed ie 1 or 2 ops per cycle if paired right. He breaks the
instruction set down into many groups, the fastest, the oks, the
maybes, the never use ect, & the whatever.

If you build a risc to execute those 1st 2-3 groups you would have a
risc that doesn't execute most x86 code since most compilers probably
generate some of the lesser codes from time to time. Also the risc
would suffer the same horrible design decisions that Intel made almost
30yrs ago. IE var length byte encodings.

Now as any AMD/Intel person would say, even though its horrible, those
wierd var length ops are understood, its possible to do in VLSI with
transister muxes very well so it becomes a minor headache. But FPGAs
are expensive to use muxes to the extent x86 needs them.

The alternative is to use time based state machine to peel the ops
apart but that would be very slow.

I would suggest staying away from x86 ISA as being the most complex
underpowered ISA around.

I would suggest staying away from Arm as their lawyers are aggresive,
but it is a much easier target.


regards

johnjakson_usa_com

 

[khoa nguyen]

johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0402280624.5fed26ec@posting.google.com>...

"khoa nguyen" <jeffn@ihug.com.au> wrote in message news:<c1p5k1$5sm$1@lust.ihug.co.nz>...
I'd like to support the ARM and IA32 ISA on an FPGA. At the moment Im unsure
if I can do this. So what I thought is that if only I have some small clean
test bench of both ISA's, then I could start supporting those small set of
instructions. Later on I would add in the rest.

Im wondering if there's anyone that happens to have some small clean test
benchs or even applications, then could you forward them to me.

thanks heaps.

About the time when Pentium 100 was introduced, there were a number of
authers that wrote books on optimising x86 code to run as fast as
possible. I have a few of these but in the office so I can't recall
names v books.

The jist of one of these " ... Inner Loops ..." was that if you
limited yourself to certain ops, you could get x86 to perform very
well indeed ie 1 or 2 ops per cycle if paired right. He breaks the
instruction set down into many groups, the fastest, the oks, the
maybes, the never use ect, & the whatever.

If you build a risc to execute those 1st 2-3 groups you would have a
risc that doesn't execute most x86 code since most compilers probably
generate some of the lesser codes from time to time. Also the risc
would suffer the same horrible design decisions that Intel made almost
30yrs ago. IE var length byte encodings.

Now as any AMD/Intel person would say, even though its horrible, those
wierd var length ops are understood, its possible to do in VLSI with
transister muxes very well so it becomes a minor headache. But FPGAs
are expensive to use muxes to the extent x86 needs them.

The alternative is to use time based state machine to peel the ops
apart but that would be very slow.

I would suggest staying away from x86 ISA as being the most complex
underpowered ISA around.

I would suggest staying away from Arm as their lawyers are aggresive,
but it is a much easier target.


regards

johnjakson_usa_com

The short term goal of what Im trying to do is to be able to run IA32
and ARM instructions, and obtain some data; hence, the need for some
test bench, which starts off simple and clean. I'd like to find out
the problems of doing that. If it cant be done then i'd like to find
out why ... the hard way! I'd like to thank you John for your
advice about ARM's lawyers. But i do not know the ramifications you're
implying. Could you explain it further if possible.

Im not really interested in optimizing IA32 at the moment. But the
book you mentioned might be a starting point for me to learn about
IA32 optimization. Could you dig it up for me, and send me its title,
author etc.

If possible I'd like to support more ISA on FPGA. And be able to run
codes on just a one machine.

thanks john,
khoa.

 

[Jon Beniston]

I'd like to thank you John for your
advice about ARM's lawyers. But i do not know the ramifications you're
implying. Could you explain it further if possible.

ARM have several patents that cover various features within their
architecture (exception handling / mul/mac instructions etc). They
have been known in the past to bully individuals / companies in to
stopping their projects/products that they believe infringe on their
patents.

Search the web for nnARM and picoTurbo.

Cheers,
Jon