Re: The variable bit cpu
- From: randyhyde@xxxxxxxxxxxxx
- Date: 30 Jul 2005 17:54:38 -0700
Skybuck Flying wrote:
>
> However looking at the big picture the effort to scale fixed bit hardware
> and fixed bit software around the planet and maybe even in space requires
> much more effort and could be described as even more expensive ;)
Not really. The "scaling" is already done in fact. However, instead of
associating the "bit size" information with memory data, it's
associated with the instruction. E.g., most 32-bit CPUs (x86 is the
obvious exception) use 2 (or more) bits to determine the operand size.
However, those bits are kept in the opcode rather than in each memory
location.
Consider this, if you want bit address and bit sizing, it will take up
to six bits to describe an arbitrary size between 1 and 64 bits. With
eight bits you can go all the way to 256 bits. By your scheme, you can
only specify sizes up to eight bits in length with eight size bits.
And while a *few* applications might need to scale beyond 256 bits,
they're going to be very rare. For that matter, few apps are going to
need to scale beyond 64 bits.
>
> As I already described the scanning can be done while the cpu loads or even
> executes the variable bit fields/instructions.
Don't think that it's free, though. That's the one main thing that came
out of the RISC vs. CISC debate -- you can't stick arbitrary hardware
on your CPU, even operating in parallel, and not have it affect CPU
performance.
>
> I think as a software programmer I have reached my goal in describing a
> variable bit field format.
>
> The variable bit field format could be used to described:
>
> cpu instructions
> memory locations
> anything really.
A better solution, based on huffman encoding, is to embed the size
information in the data stream itself rather than using "tag" bits.
E.g.,
$00..$7f -- Values in the range 0.127 or -64..+64,
$8000..$bfff -- Values in the range 0..16384 or +/- 8192.
etc. (Note that this require big endian encoding to make sense).
Same sort of trick used by UTF-8 and other variable length encodings.
Fairly easy to extend from byte address to bit addressing actually. And
relatively memory efficient.
>
> The implementation of variable bit cpu/hardware (using this variable bit
> field format or a similiar design) is left as an exercise to the
> hardware/software reader/implementator ;)
Of course it is. But keep in mind that the devil is in the details.
Tag bits have been used in memory systems for various purposes over the
years. They've never proven very popular in mass-produced products
because of the cost and complexity involved. But look up "associative
memory" on the Internet if you want to read some fascinating ideas.
> >
> > It won't save cost, it will be far more expensive. At the very least,
> > you've doubled the memory requirements. How much you'll save by not
> > having to waste a few bits in certain data types is questionable. Most
> > applications will continue to use data sizes that are powers of two,
> > anyway.
>
> In the long run it will prove to be cheaper since the software will be able
> to scale indefinetly.
But do we need this?
Already, few applications are going to benefit by having greater than
32-bits available for anything beyond addresses. And 64 bits of address
is pretty much infinity as far as memory is concerned (keep in mind, 64
bits of address space will handle byte addressing on something like *4
BILLION* DVD-ROM disks!). Somewhere around 2**80 you've accounted for
all the bits in the known universe. Certainly we don't need much in the
way of addressability beyond 64 bits. And already, few apps need
integer numeric values beyond 32 bits, much less 64. The idea might
have been cool back in the days of eight-bit processors, but we've
already scaled about as far as we're going to. No doubt, 128 bit
processors will come along, maybe even 256 bit processors. But we're
not scaling much farther than we are today.
> >
> > There are other ways to do this. See the address displacement values
> > found on the National 32000 series family (I think the VAX did this,
> > too, but I'm not sure).
>
> Yes, there might be other ways to do this but are they as simple as this ?
Conceptually, the idea is simple. But the hardware support is not. As I
said earlier, the devil is in the details (of the hardware
implementation).
>
> The idea is about flexbility, scalability and easy of use.
Except we don't need that kind of scalability today.
>
> With these three properties combined and new ways of thinking comes pure
> power :D
No doubt, those tag bits could be used for some very interesting
things. Indeed, tag bits *have* been used for interesting thing. But
those things were never economic and, dare I say it?, they didn't scale
well to different systems.
> >
> >
> > >
> > > Example are windows xp 32 to 64 bit, the internet IPv4 to IPv6.
> >
> > That won't fix the problem where the code assumes a certain bit size.
>
> "Code assuming a certain bit size" is part of the problem.
You're either burying the size in memory as part of the data, or in
memory as part of the opcode. Either way, someone has to make the
decision about the size. And dynamic sizing is going to be difficult
to pull off. What happens when you have this:
0000001000000010000001
xxxxxxxyyyyyyyyzzzzzzz
And you decide you really need this:
000000000001000000010000001
xxxxxxxxxxxxyyyyyyyyzzzzzzz
then what? Are you going to shift everything around in memory? As I
said, someone's got to make the size decisions at some point and
changing them later is going to be a problem.
>
> The whole point is more flexibility in the software.
But the hardware costs aren't going to allow it. Your's is the CISC
approach -- have the hardware do everything. We've learned the hardware
that having the hardware do everything winds up slowing things down
tremendously.
>
> The variable bit format is to be used to make the software scale to (in
> theory) unlimited bit size.
But is unlimited bit size necessary?
80% of the integer numeric data I process can be handled by 16-bit
integers. 98% can be handled by 32-bit integers. 99.9% by 64-bit
integers.
And even if that were the case, I don't see your scheme scaling up any
better than using traditional approaches to multi-precision arithmetic.
In those few instances where I need 128-bit integer arithmetic, it's
easy enough to do on a 32-bit or 64-bit CPU.
And one *big* thing you're missing here is that have a variable-bit
size in memory *doesn't* give you a variable-sized ALU for arithmetic
operations. Therefore, you can't have unlimited size arithmetic
operations without having the hardware do the multiprecision operations
for you (slow).
The advantage to your scheme is not that it allows unlimited precision
arithmetic, but that it lets you *exactly* specify an operand's size
down to the bit, without wasting any bits. That is, at first blush it
would seem to be very memory efficient. Until, of course, you remember
that it takes two bits of memory for each bit you want to represent.
At which point it's clearly more space efficient to use nice
Power-Of-Two sizes.
>
> Using this variable bit format requires the programmer to think a little bit
> different about programming and formats etc.
Sure. They have to pick their *exact* bit sizes ahead of time, allowing
for overflow and the like. And in the end, they're probably going to
pick sizes like 8, 16, 32, and 64 bits. At which point all that tag
memory will go to waste.
Cheers,
Randy Hyde
.
- Follow-Ups:
- Re: The variable bit cpu
- From: Skybuck Flying
- Re: The variable bit cpu
- References:
- Re: The variable bit cpu
- From: randyhyde
- Re: The variable bit cpu
- From: Skybuck Flying
- Re: The variable bit cpu
- Prev by Date: Re: Alignment
- Next by Date: Re: Alignment
- Previous by thread: Re: The variable bit cpu
- Next by thread: Re: The variable bit cpu
- Index(es):
Relevant Pages
|
