Re: The variable bit cpu

"Skybuck Flying" <nospam@xxxxxxxxxxx> wrote in message
news:dchibn$h6g$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
[...]
> Assuming the CPU and the main memory are seperated the communication
> between
> these two could take place in serial as pointed out by others thank you ;)

What do you mean by serial? Surely you don't mean a bit at a time; memory
throughputs of a few gigabits per second are not a big deal these days, but
off-chip clocks of a few GHz most certainly are. Of course you can do block
transfers of the width of your physical bus, as many as you need to get
whatever bitstring you are after, but that is a nasty piece of hardware to
design; and again, when you read that 600-bit field, where do you put it?

> The CPU could act upon "virtual registers". These registers could be
> located
> in the main memory at certain logication and changed in location and/or
> size
> after or during boot.

It could, but that defeats the purpose of having registers. The reason why a
processor has registers, instead of just always working on external memory
(or cache or ...) is that it is possible to make registers that can be
accessed very, very quickly. It is not practical to make a memory of any
size that can be accessed that quickly. A typical RISC processor can barely
do anything with a piece of data without loading it in a register first.
That has turned out to be a very practical design choice; witness the
success of the ARM7, for example.

[...]
> Assuming there are two variable bit fields that need to be added the
> process
> is as follows:
>
> I'll call these two fields: field A and field B.
>
> Field A flows through the system via serial bit stream line 1.
>
> Field B flows through the system via serial bit stream line 2.

It really seems a lot like you are imagining that 1 bit moves every clock.
That is good for academic examples (hence the jokes about the Turing
machine; that is a very simple design for a computer that is often used for
theoretical purposes), but it does not tend to make a practical design.

> The CPU for example or whatever you want to call it scans both bit streams
> until the end bit is detected.
>
> The CPU could use fixed bit registers under water.
>
> Suppose Field A is 4000 bits big and Field B is 50 bits big.
>
> Suppose the CPU has 32 bit registers underwater.
>
> Only the last 32 bits of Field A and Field B will remain in the two
> register
> after the scan is complete.
>
> For this to work the registers need to use what I call a "push out"
> system.
>
> <--- most significant ---| -----------------------| <--- least
> significant
> <--- bit push out ------ | register 32 bits of data | <--- bit pushed in
>
> Once the scan is complete the least 32 bits are in the register and can be
> added together.
>
> Now the bitstream flows back through the system in reverse order etc.

That doesn't make any sense to me at all. If you want to add a 50 bit number
to anything using a 32-bit adder, then you have to add at least twice.
Anyways, if you were only moving 1 bit every clock cycle, then you could
just use a serial adder and you wouldn't care about this. You could build a
machine with no registers at all, that always worked on external memory. It
would be slow as hell, but you could. If it read the data one bit at a time
then you could use one-bit arithmetic units too. At that point you have a
one-bit computer, not a variable-bit computer....

>
> Since only one line is needed for bitstreams... maybe multiple bitstreams
> can be combined to speed up the processor for multi tasking/concurrent
> processing etc ;)

So that you have multiple instructions executing at once, you mean? Of
course big 'desktop' processors can and do schedule instructions on their
own, so that they could do a bit of that. They are not very good at that,
though. There are DSPs and other specialized processors that let you do the
scheduling yourself; these work extremely well for the narrow application
for which they were designed (lots of convolutions at once, or whatever).
They are not very easy to program for anything else.

> Just some ideas... what do you think ? :)

Let me put it this way: the most exciting new instruction set in 'recent
history,' looking at commercial success and not weird academic projects that
I don't know anything about, is probably the ARM. It does not even support
unaligned 32-bit loads. That means that if you want to access a 32-bit
variable at an address that is not evenly divisble by four, then you must
write special software; you can't just load or store. I have not seen anyone
upset about that. If you need it then you just specify __packed or whatever,
and the compiler generates appropriate instructions.

I think that it is often a good idea to use variable-length data formats. I
think that a variable-length register is insanity. I'm sure it's been done
though. Does anyone know where?

[...]
> I expect fields to grow when needed, allowing a never before seen
> flexibility in communication, storage, processing etc ;)

There is nothing in the instruction set of any processor that I have ever
seen that makes it impossible to implement a variable-length field. It is
just a matter of whether the programmer chooses to. The programmers are
working so many layers of abstraction above the instruction set that I doubt
that it makes much of a difference to them.

[..]
> With distribution you mean many little fields followed by a big field etc
> ?
>
> Why is this a relevant question ? I assume maybe for some optimizations ?

I did not mean the order, although you might also be able to exploit that
sometimes. If you expected many fields of just a few bits, then your scheme
might be plausible. If you expected that all of your fields would be between
100 and 200 bits in length, then you might use a string of 8-bit (unsigned
binary integer) lengths instead of your Turing machine style unary
representation. That would consume 8 bits extra per field, instead 100 to
200 bits extra per field. If you expected that the fields would usually be
under 256 bits long but not always, then you could specify an 8-bit length,
but say that length==255 means 'read another length octet, add 255 to it,
and use that for the length.' People do things like this all the time, in
software.

Jonathan


.

Relevant Pages

  • Re: The variable bit cpu
    ... what changes to the instruction set would you make to address data ... Possibly little changes since the cpu can detect the size of each variable ... Assuming the CPU and the main memory are seperated the communication between ... The CPU could act upon "virtual registers". ...
    (sci.electronics.design)
  • Re: Thread - Shared Memory
    ... > Is there really no other way to do Shared Memory IPC without synchronization? ... CPU that the data that it's holding in registers and cache are needed ...
    (comp.lang.java.programmer)
  • Re: New itaniums out at 2.5x perform gain
    ... because CPU and "memory management" functions have been integrated (read ... The memory management system allowed the CPU to address memory using ... memory management registers. ... 16-bit data bus, 24-bit address bus, considered to be ...
    (comp.os.vms)
  • Re: Intro to Programming w/ Machine Language
    ... This teaching method of simulating a computer reminded me of an old ... for input, a little "printer" for output, the exposed CPU, and about 15 ... Every time you stored a number into a memory location, ... Although the reviewer thought that the instruction set was too limited ...
    (comp.programming)
  • Re: Intro to Programming w/ Machine Language
    ... This teaching method of simulating a computer reminded me of an old ... for input, a little "printer" for output, the exposed CPU, and about 15 ... Every time you stored a number into a memory location, ... Although the reviewer thought that the instruction set was too limited ...
    (alt.lang.asm)