Re: The variable bit cpu


"Walter Roberson" <roberson@xxxxxxxxxxxxxxxxxx> wrote in message
news:dcj0g2$d7n$1@xxxxxxxxxxxxxxxxxxxxxxxxxx
> In article <dcgia6$l6r$1@xxxxxxxxxxxxxxxxxxxxxxx>,
> Skybuck Flying <nospam@xxxxxxxxxxx> wrote:
> >I think I might have just invented the variable bit cpu :)
>
> >The reason for the variable bit cpu with variable bit software is too
save
> >costs and to make computers/software even more powerfull and usefull ;)
>
> >For example:
>
> >Currently fixed bitsoftware has to be re-written or modified,
re-compiled,
> >re-documented, re-distributed, re-installed, re-configured when it's
fixed
> >bit limit is reached and has to be increased for example from 32 bit to
64
> >bit etc.
>
> The implication of your example is that the software would dynamically
> expand fields as necessary to hold results -- e.g., if a result
> would overflow 16 bits, then use 17 (or 18 or whatever) instead.

Correct.

> You weren't just thinking in terms of application programs that might
> have to deal with the OS deciding to use larger fields file sizes, for
> example]: the example you gave was Windows -itself-. Thus, you aren't
> just thinking "Ah, Adobe Acrobat wouldn't have to be recompiled to go
> from Windows XP Pro to Windows XP Pro64, even though XP Pro64 had to be
> changed", you are thinking "There would be only one Windows XP Pro"
> and that implies that the system would be expected to adjust
> size fields according to the needs of calculations, not just
> that it would be able to work within upper-bound size limits
> handed down by other parts of the system that were [inherently]
> compiled with fixed sizes.
>
> So... dynamic sizing of results.

Correct.

>
>
> Now, dynamic sizing of results has some... interesting... properties
> when it comes to C programs. One cannot, for example, allocate
> a fixed amount of storage for array entries, because the different
> entries might have different sizes, and a field that is (say) 3 bits
> wide now might suddenly become 115 bits wide; in a traditional
> linear-storage machine, that would require that all the other entries
> "scoot over" and that pointers somehow auto-adjust.... unless you
> want to spend most of your time just running through from the
> beginning of memory trying to figure out where the 29563'rd field starts
> (Repeat the calculation after every STORE that changes a field size...)

..NET does something similiar, shifting over memory etc, it's not too shaby
;)

> This suggests that in order to use such a scheme, that an address /
> "pointer" would have to be a field number, and that *behind the scenes*
> the processor would be keeping track of where in the linear bit store
> the data really was. Memory fragmentation would be a way of life,
> but fortunately because -every- access would be indirect, the
> processor could pause and do de-fragmentation without affecting
> the addresses / pointers as known to the programs. Could present
> some interesting challenges for real-time programming...

Nice idea ;) Indeed a little gremlin is behind the scenes taking care of
things ;) and I don't mean killing :D

Personally I dont like gremlin's.

But it could be too much to ask of programmers to fix the system when
fragmentation becomes high or when memory is low etc...

So the damn little gremlin can take care of it :)

>
> Dynamic sizing of results has some real symmantic challenges.
> In the below x#y indicates data bitfield x with "marker" bits y.
>
> - Signed and unsigned additive operators can no longer be treated
> equivilently in internal logic. For example, in a standard 8 bit
> 2's complement machine, 0xFF + 0x01 is 0x00 no matter whether the
> 0xFF is signed or unsigned. In a variable-bit automatic-extension
> machine, signed 11111111#00000001 + 1#1 -> 0#1
> but unsigned 11111111#00000001 + 1#1 -> 100000000#000000001

So far I have only thought about positive stuff ;)

I never liked the idea of using half the bits for negative and half the bits
for positive for an integer while the same ammount of bits is used for full
positive in an unsigned integer.

Both examples look exactly the same and I don't like that because it's
confusing.

So I rather see that the first bit is used to indicate positive or negative.

Positive would be a leading 1
Negative would be a leading zero

But since I also want extra space for performance reasons (avoiding
fragmentation)

I think I would add a special bit field to indicate positive and negative
values :) saves me a whole lot of *** :)

sign bit ;)

for data fields those bit is irrelevant and could maybe be used for other
purposes ;)

Maybe I am just gonna add a data type field as well... I kinda like the idea
of the processor being more aware of what is flowing through it ;)

So it could look as follows:

data type + data

0 is unknown/general data
1 is numerical data

here a branch takes place
seeing a 1 then next field would be:

the sign bit
0 negative
1 positive

following that are the numerical bits.

Because fragmentation can be a real problem etc I am going to allow the
following :)

000000000000000#000000000000001

and also
000000101011101#000000000000001

So any number of leading zero's can be applied as long as the "marker mask"
is of equal length.

So this format exploits the knowledge of the smarter programmer.

The smarter programmer can still specify how much bits he needs he thinks
for each field.

However the programmer should always keep in the back of his mind that these
fields are allowed to grow...

as soon as the fields is like this:

1111#0001

And +1 is added. it will have to grow to:

10000#00001

Compilers could be smart and reserve some space between the fields so that
fields can grow in both directions.

For example the compiler might place this 4 bit field like this:

1010101#0000001#00000000000#1111#0001#000000000000000000

Then when the field needs to grow it looks like:

1010101#0000001#0000000000#10000#00001#00000000000000000

There should also be directives and maybe even routines to specify that this
is unwanted behaviour for some cases
where the bits need to be packed.

For example network communications could be slow and things can be speeded
up by removing the extra bits. (packing)

1. This option implies special routines which can be called by the
programmer/program at any time to for example package a structure ;)
right before it is send or stored etc... however if speed or space is not
important all extra bits inbetween can be stored as well... though this
could be risky
if there are lot's of them in between ;) :) though since it would be part of
a structure this would be unlikely ;) and if it does happen to bad... pack
it ;) :)
The program could be fed extra information about the structure for example:
The content size of the structure (counting only the content bits)
The real size of the structure (couting content and extra bits in between)

The program can then make a decision that if the percentage of extra bits is
low... whatever low means ;) the program can simply choose to write the
extra
bits in between as well to allow future growth directly into the file... and
to save cpu processing etc.

2. Or by simplieing making sure that the fields are packed from the start.
(packed)

The last option implies that stuff needs to be shifted/moved around etc...
this means a directive that the structure should be packed at all times.

>
> The compiler does, though, know the difference, and could generate
> appropriate instruction sequences, but I suspect that a lot of existing
> code relies upon 2's complement equivilences.
>
> - Quick, what is the bitwise "not" of 0#1 ?
> Is it 1#1 ?
> Is it 11111111#00000001 ?
> Is it 11111111111111111111111111111111#00000000000000000000000000000001 ?
> Is it a string of 1's that fills up all of available memory?
>
> The answer pretty much has to be that (~ unsigned 0#1) is
> "extensible" 1#1. It would be tempting to say that "extensible 1#1" is
> the same as "signed 1#1" -- but extensible unsigned 1#1 and signed 1#1
> have different properties for addition, as indicated above.
>
> In a system with dynamic sizing, what should
> 1 + ~ (unsigned 0) *be* ?

Ok I ll interpret this as:

positive 1 plus the reverse of zero

since I have added a sign bit... positive zero... will turn to negative zero
and negative zero will turn to positive zero...

For the cpu it's all the same.. since zero is zero ;) at least for us humans
and that's how the cpu will work too ;) unless somebody has any objections ?
:):):)

so we humans do +1 + - 0 = 1
or
so we humans do +1 + + 0 = 1

>
> One cannot say that this is simply a degenerate case that will not
> come up in practice, as ~ and | and subtraction (and I do not mean xor)
> come up a fair bit in IP address / netmask / broadcast address
> calculations.

I think you mean same question but different operator ?

Like

1 or (unsigned 0) ? = 1 ;)

I see absolutely no problems at all at this point....

Since we designing a new cpu we can build in any special handling where
needed...

Maybe we get problems with multiplications or division or something like
that...

But so far I see no problems at all ;) :)

>
> - What do you do about floating point numbers, seeing as you want
> XP and XP64 (with different floating point limitations) to be the
> same binary image? Your thesis of not needing to recompile implies
> that code cannot assume 32 bit single-precision float, since the same code
> might, 2 or 3 hardware generations down the road, be expected to
> operate on 512 bit floating point *without any change or recompilation*.

Floating point numbers are a big no-no, since they are imperfect and fixed.

So floating point numbers go out the window ;)

No floating point numbers for me :)

Instead the software can use special software which performs calculations
with stuff like 1 / 8 + 2 / 8 = 3 / 8 etc...

Maybe this special kind of software/calculations can be build into the cpu.

I am not going to infect my cpu with inperfection :) floating points are
inperfection ;) :):):):):)

However I haven't though yet about how to handle floating point like stuff
user friendly etc... with dot's in them etc...
like 56.89

Maybe this will just be translated into 56 + 89 / 100

56 is stored in memory and 89 and 100 is stored in memory.

I don't know the english word for this kind of thing... like a fraction ? or
broken number ? I dont know ;)

Anyway since the numbers can now be infinite in theory they can be very
large in practice as well.

So huuuugggeee floating point like stuff would be possible :)

It would look like a floating point but it's not really a floating point :)

At least not the floating point format...

The floating point format will be something special which also uses the
variable bit fields ;)

Hmm let see...

Maybe something like this:

# whole number # marker # broken number # marker # thousands # marker ;)

with a data type and a sign type in front of them.

0 was unknown data type
1 was numerical data type... maybe I should call this integer type after all
;)
2 will be floating point data type :)

>
> - In order to avoid locking in formats for values that could change
> in size, [v][s]printf() formats would generally have to be
> variable. %d vs %ld would generally have to disappear, in favour
> of a generalized integral format. (Fixed-width reports would take
> rather a severe hit...) But then what do you do if (for example)
> asked to print out the hex representation of that
> "extensible unsigned 1#1" ? How do you know when to stop extending
> it? The correct answer today on "64 bit hardware" might be the wrong
> answer for tomorrow on "256 bit hardware". Indeed, I would suggest
> to you that the "correct" answer would depend upon the individual
> reader of the output...

Euhm the above stuff about printf etc is too c library like specific, you
lost me ;)

Thanks for your post, it forced me to think about a lot of new stuff which I
hadn't thought about before...

I think I have given you some great answers...

Now it's time for others to analyze it to find any flaws in them :D

Bye,
Skybuck =D


.