[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] New 64bit instructions for 32bit processor cores analogy
Hi Paul,
It sounds to me that today we have some ways to go:
- Larger instructions: Like VLIW. which try to turn explicit the
instruction paralelism. May loose bits.
- Smaller instructions: Use lots of simpler instructions to do
something. May need some extra instructions to code a simple operation
- Mixed instructions: CISC machines. Use just the exact number of bits
needed to encode the instruction.
- A Small Large instruction: Use the first approach but try to code it
in a compressed way (like CodePack, Thumb, MIPS16, etc.)
As I understood from your message, you are trying to find an
intermediate point between complex instructions and simpler ones. But
you should notice that still in 32-bit instructions, you have unused
bits (more than 25% on average for MIPS32 instruction space!), which can
make possible the insertion of new instructions without increasing its
size. As noticed in the MIPS16 and Thumb, most of the immediate fields
uses less bits than the available number. Did you tried to encode your
instructions in 32 bits?
Another point you should note, is that simpler instructions helps the
compiler and then you get smarter code. It is not so easy to design
compiler optimizations for complex instructions and that is one of the
main features of the RISC architectures. It doesn't matter how fast can
be your instruction set if you do not have a good compiler.
Rodolfo
Paul McFeeters wrote:
>
> Victor,
>
> 8bit cpus? The goal with the enhanced (vs. new) instructions
> is performance. The original message was to detail an idea
> that 32bit processor cores could work smarter not harder
> (RISC or CISC) using 64BIT INSTRUCTIONS to reduce the
> amount of clock cycles required to achieve the same task
> with the processor. The examples I citied were a CMP/JMPcc
> combination and a memory/register move whilst performing
> another operation on the code, ADD, SUB, OR, AND, etc...
>
> True all our instructions today are based upon the instructions
> of years ago. I don't think since the 68000 appeared there has
> been any major jumps in instruction development (to the best of
> my knowledge). Most people appear to have stuck to the tried and
> tested old-faithful ones. Even when RISC arrived, yes they reduced
> the instruction count but the ones left were just the same old same
> old (a few manufacturers might have added new ones just for their
> own RISC designs).
>
> Who says because we have a 32bit processor core it has to use 32bit
> data path? Anybody who says that had better look at every Pentium
> ever made. They all do it but still they have what I consider 'dumb'
> instructions.
>
> Easy CPU analogy for non-assembler programmers
>
> Imagine you had two rooms, one is where you receive instructions via
> a tube (like in the film Brazil) and the other room has boxes and is
> where you carry out the instructions sent to you. In the 'old school'
> way of doing it a CMP/JMPcc is like the following:
>
> You receive a message-tube saying "go into the box room" and check to
> see if there is a blue box. After you return from looking for a blue
> box you return to the message-tube. The new message says "if you did
> find a blue box then place it under the window". So you return to the
> box room and move the blue box (if there is one) to under the window.
>
> Okay so now for my way of doing it with 64bit instructions.
>
> You receive a message-tube saying "go into the box room, if you see a
> blue box then place it under the window". You go into the room and move
> the blue box (if there is one) under the window.
>
> 'Old School' for the move/add (add could be any other ALU operation)
>
> You receive a message-tube saying "open the red box and take its contents
> out". So you go into the room and remove the contents from the red box.
> Another message tube arrives which says "take half of what you are holding
> and put it into the yellow box". Which you go off and do.
>
> Okay so now for my way of doing it with 64bit instructions.
>
> You receive a message-tube saying "open the red box, take half its contents
> and put them into the yellow box". Do you this and return to the
> message-tube.
>
> Hopefully you can now see how by expanding the instructions to 64bit can
> produce more powerful versions of the 'old school' instructions. Whilst
> there are a quite few more instructions that can be enhanced in this way
> there are also some that just can't be enhanced at the moment (e.g. INT).
> Obviously
> all my alterations are designed to decrease the number of clock cycles
> required
> for the most common assembly operations. This is very similar to the reason
> behind
> the birth of RISC which was the fact that CISC program execute 20% of
> instructions
> 80% of the time. If you optimise the 20% of instructions to run twice as
> fast and
> everything being up to the job then your CPU will run the same program now
> 1.8x
> times faster than before. The only drawback to my system is that programs
> will grow
> by at most 2x (more like 68% in my real-world tests). Considering the way
> the MS
> PC operating systems have grown in 15 years from DOS on two 180K floppies to
> Win2K
> needing a whole Gigabyte just to install my system actually looks bloody
> efficient.
>
> As most memory now ships in 64bit wide DIMM modules just how long is it
> before
> CPU designers start taking proper advantage of it?
>
> Paul McFeeters
>
> -----Original Message-----
> From: owner-cores@opencores.org [mailto:owner-cores@opencores.org]On
> Behalf Of Victor Snesarev
> Sent: 10 December 2001 20:51
> To: cores@opencores.org
> Subject: Re: [oc] Processor Instruction reply for Andreas
>
> --- Paul McFeeters <paul.mcfeeters@ntlworld.com>
> wrote:
> > Andreas,
> >
> > > > Old Way:
> > > >
> > > > CMP AX,$2000
> > > > JC #4000
> > > >
> > > > Two instructions to do that? Why use two clock
> > cycles for that? Can't we
> > > > just have a CMPJxx instruction? Takes two
> > values/register combinations
> > and
> > > > based upon the results of the comparisons jumps
> > to the destination or
> > not.
> >
> > > There are two things to be done. A subtraction
> > and a conditional jump.
> > > Just because you put them in the same instruction
> > doesn't make them in
> > > one cycle. If they do execute in one cycle, I
> > guess the cycles on that
> > > machine are generally longer.
> >
> > Wrong. I tested it out and it makes simple sense.
> > When a compare is done
> > then
> > the HDL copies the value of '1' into the relevant
> > flag. As any HDL
> > programmer
> > will tell you copying a 32bit value versus 1 bit
> > doesn't take a ps longer so
> > my way is quicker.
>
> <snip>
>
> I'm not a CPU core developer nor do I have years of
> experience programming in assembler, and I haven't
> been following this thread, so pardon any
> misunderstandings... But I think the reason these sort
> of things used to be done in two instructions is
> because there weren't enough bits to encode
> instruction opcodes. Having CMPJxx, JSRxxx, and so on
> would chew up too many opcodes for an 8-bit CPU.
>
> Victor Snesarev
--
The Xingo Project | Rodolfo Jardim de Azevedo
Code Optimization for Embedded Systems | Computer Science PhD Student
An Open Software Initiative of IC-UNICAMP | rjazevedo@ic.unicamp.br
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml