Re: The variable bit cpu


"Jonathan Westhues" <google-for-my-name@xxxxxxxxxx> wrote in message
news:V6TGe.6695$d02.1023331@xxxxxxxxxxxxxxxxxxxxxxxx
> "Skybuck Flying" <nospam@xxxxxxxxxxx> wrote in message
> news:dcgrv9$eu3$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
> > It works simply like this:
> >
> > Each "data bit" has a "meta data bit".
> >
> > The meta data bit describes if the bit is the ending bit of a possibly
> > large
> > structure/field.
> >
> > The meta bits together form a sort of bit mask or bit pattern.
> >
> > For example the idea is best seen when putting the data bits
> > and meta bits below each other.
> >
> > data bits: 01110101110101101010101
> > meta bits: 00000000100010001100001
> >
> [...]
> >
> > The above example then looks like this:
> >
> > data bits: 011101011#1010#1101#0#10101
> > meta bits: 000000001#0001#0001#1#00001
> >
> > (The # sign is too indicate to you where the variable bit fields are.)
>
> Are you familiar with the instruction sets of any general-purpose
> microprocessors (x86, ARM, etc.)?

A little bit.

> If so, what changes to the instruction set would you make to address data
in this format?

Possibly little changes since the cpu can detect the size of each variable
bit field.

> Remember that memory buses do have to have a fixed (or at least maximum)
width--a 16-bit parallel flash
> chip has 16 physical data pins, i.e. little pieces of metal that solder to
> the printed circuit board, one for each bit in the word. That is not
> something you can change at run time! Similarly, registers in a CPU must
> have a fixed length, or at least some maximum width; each bit in a
register
> corresponds to a physical flip-flop and some other circuitry on the chip.

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 ;)

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.

The main memory chips might have extra logical to perform local memory
copies inside the memory chip itself or maybe even other operations.

Alternatively the CPU could just have a few bits to do it's thing.

Start simple ;) then look how to improve upon it... that might be the best
way to go along :D

>
> How do you think this would work with arithmetic operations, for example?
> The hardware to perform operations like addition and subtraction operates
on
> many bits in parallel, for speed. That means that the chip designer must
> decide how large of a number the CPU can add in a single instruction (or
in
> a single cycle at least). If he designs a 32 bit-wide adder, then the CPU
> will be able to add two 32-bit numbers very fast, probably in a single
> instruction cycle. If he chooses an 8 bit-wide adder, then the CPU would
> take much longer to do that, at least four cycles. However, the 8-bit
adder
> consumes much less area on-chip than the 32-bit adder. How would you
handle
> that with your 'variable bit' idea?

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.

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.

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 ;)

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

> Your format allows arbitrary-length fields, but it requires 2*n bits to
> store n bits of data. A fixed and predefined layout would only require n
> bits to store n bits of data. Can you think of a good compromise between
> those two extremes?

Dynamic Compression like huffman but sometimes that might even produce more
bits ;)

> Do you expect many small fields, or fewer large ones?

Good but maybe a tricky question ;)

Current software has little choice but to choose small fields :D

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

> What is the distribution? I think that you will find that almost any
scheme
> is nearly optimal under some set of assumptions, but what kind of
> assumptions are reasonable?

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 ?

> Regardless of the format that you choose, do you
> think that it is necessary to make changes to the instruction set to
support
> that format?

Maybe not :) see above ;)

> If so, what does it gain you?

Incredible flexibility of binary software which impacts storage,
communication, processing etc.

> The design of a new instruction set is a very specialized area. Most of
the
> people who design new instruction sets have a very good idea of what kind
of
> problems people use computers to solve, and what kind of instructions make
> life easy for the compiler (and what language someone will want to write a
> compiler for), and so on.
>
> If you are interested in this field then maybe you would find it more
> rewarding to look at little problems. For example, your pocket calculator
> probably has some sort of custom microprocessor in it. What kind of
> instructions would you need if you only want to build a four-function
pocket
> calaculator, and nothing else? That is a much more manageable sort of
thing
> to design, because the problem that you are trying to solve is much more
> constrained.

As I grow older and gain more (programming) experience etc I find myself
more interested in what happens in lower layers :)

For different reasons... understanding/solving/exploiting/modifieing
performance bottle necks, inflexbility, vulnerabilities,system workings etc
;)

Bye,
Skybuck.


.

Relevant Pages

  • Re: kernel problem
    ... Scanning 0 areas for low memory corruption ... CPU: L2 Cache: 512K ... Performance Events: AMD PMU driver. ... generic registers: 4 ...
    (Linux-Kernel)
  • Re: The variable bit cpu
    ... Surely you don't mean a bit at a time; memory ... > The CPU could act upon "virtual registers". ... There is nothing in the instruction set of any processor that I have ever ...
    (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)
Quantcast