Re: [oc] New 64bit instructions for 32bit processor cores analogy

[Victor Snesarev <vnsnes@yahoo.com>]

Paul,

I definetly see your point, and I am not arguing it. I
just thought I'd throw in my 2 cents, and it turned
out not to fit the topic quite well.

The sort of thing you are talking about (I think) is
done heavily in DSPs (I'm familiar with Motorola 
DSP56xxx family architecture) where you have MAC
(Multiply and then Accumulate) instructions, many
conditional jumps and branches, an IFcc instruction,
and loops that are executed in hardware. In addition
to that you have a plethora of addressing modes that
are designed to accomodate different data structures.
You can also perform up to 2 data moves in parallel
with ALU instructions:

mac x0,y0,a   x:(r0)+,x0    y:(r1)+,y0

This instruction iterates through two data buffers
pointed to by r0 and r1, doing a multiply+accumulate
on their respective members. I think the instruction
is encoded in 24 bits.

I hope I'm a bit more on target with this post.

Victor

--- Paul McFeeters <paul.mcfeeters@ntlworld.com>
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.
> 


__________________________________________________
Do You Yahoo!?
Check out Yahoo! Shopping and Yahoo! Auctions for all of
your unique holiday gifts! Buy at http://shopping.yahoo.com
or bid at http://auctions.yahoo.com
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml