[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [oc] New 64bit instructions for 32bit processor cores analogy
Paul,
the problem will be that your harddisk will swap 4x as much and read/write
larger data or code from the harddisk. What do you think about a variable
instruction length, instead of a fixed 64 bit length? Is this possible?
Dani
Am Dienstag, 11. Dezember 2001 10.49 schrieben Sie:
> 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
>
> __________________________________________________
> Do You Yahoo!?
> Send your FREE holiday greetings online!
> http://greetings.yahoo.com
--
To unsubscribe from cores mailing list please visit http://www.opencores.org/mailinglists.shtml