The variable bit cpu

The 186/8 weren't targeted at the embedded market, but that's where they ended up after IBM mucked up the interrupts in the PC.

In article , Rich Grise wrote: [...]

I'll disagree with you since I can remember right off the top of my head that the ROL AX,2 would work for the 186 but not the 8086.

That

Essentially,

CPU

save

re-compiled,

fixed

of

Yes the idea is to re-write all software so that it uses variable bit field so that it can scale up to anything. :)

Yes I think my variable bit field allows these kind of instruction too. But for a first version of the cpu... let's first stick to the simple instruction.

By the way now that the larger processors are starting to overheat it was way too early to sell of these transmeta processors etc... these lessheat processors might become much more interesting in the future.

Oh well

Bye, Skybuck =D

...

Without trying to drag this out any longer, how about some specifics here?

For example, is your idea handing the stream of bits to the CPU least significant bit first the followed by bits to most significant bit? Or the reverse of this?

If you are doing least up to most then I can see how a 1-bit ALU can handle operations like addition or subtraction, just as long as you can stream in the two operands and be able to stream the result out all at the same time.

If you are doing most down to least then I'd like to see some convincing explanation of how you can do something as simple as add or subtract without needing arbitrary amounts of storage.

Next, if you are thinking arbitrary length strings of bits then is there anything equivalent to a "register" in your CPU? And if there is how do you hold an arbitrary amount of data in them, how can they be big enough?

Next, how do you do something like multiply or divide with your arbitrarily long streams of bits? Unless you have some really good explanation I'm not sure how your streams of bits can do this without needing to do something I don't see.

Next, what is your memory addressing going to look like? All the memory I'm aware of, other than some special forms of memory that I'm fairly sure you've never heard of, all the conventional memory deals with fixed length addresses and fixed length words of data.

So, how about some specific descriptions of how your idea is going to handle these things? If you are worried about credit then it seems that your coming out with the details will be better than having someone else taken a few clues, figured it out on their own and claimed all the credit for themselves.

In article , Don Taylor wrote: [...]

A serial multiplier is fairly easy to do. It takes N*M shifts to get the job done.

N = the number of bits in one argument M = the number of bits in the result

Dividing is a lot harder but dividing is semi-optional so it isn't too much of a problem that it takes a lot more shifts to do.

I know there are some solutions to some of the problems that he faces. I specifically didn't tell him what a solution might be to any one of them, although I did strongly hint in a couple of the things I wrote.

What I'm trying to get at is whether he has anything more than just an idea about how to have a stream of bits tell you when you have reached the end or not.

In article , Don Taylor wrote: [...]

I think we can save our brains on that one and just assume that the only idea he has is the end marker idea. He hasn't even realized what base numbering he should use. (hint: base 2 is not the right one)

Boring, it's base 2.

Does the world really need a variable bit cpu ? ;)

Maybe for nanobots but that's it.

I most come to the conclusion that the variable bit cpu is a waste of time for me... though an interesting waste of time... maybe I will work on it sometime when I feel like it... but at the moment I have lost interest ;)

There are other people who made little cpu's and where did it take them ? into the garbage bin :)

Then again it might get interested again when combining it with robotics etc... building a little spider with a camera on it would be cool :D:D:D:D:D little spiiiieeeee robot.

Hmmm yess.. maybe I should go spent sometime > >> >[...]

Guess again; the correct answer is obvious and it is not 2.

How about Pi? ...to one significant digit.

An interesting alternative would be to imbed the markers in the data as I guess you are thinking. The context in which I'm suggesting this is where the bits represent the number only and not the marker.

Remember we want a general purpose machine that can handle signed values and be variable length.

only

Base 4 ? get real.

What's wrong with base 4? In grade school we were taught to do arithmetic in all bases up to 32 (symbols got the be hard to remember ;). Are you a crappy coder; a binary bigot?

Why not? X86 imbeds instruction "markers" in the input stream. It can't be any harder to decode data.

Sure. But why waste bandwidth with a word marker per bit? (a question for the OP, BTW)

Sure, but we dropped 'O's and 'I's and such confusing things. ;-)

IBM likes base-16 for FP. Go figure.

In article , Skybuck Flying wrote: [....]

No. Four is the wrong answer. The right answer is obvious.

In article , keith wrote: [...]

Up to 36, the symbols are not that bad.

I've always kind of liked base 4 for the exponents in floating point numbers. It can save you a whole box full of NAND gates.

In article , keith wrote: [...]

Hummmm .... good point.

BTW: At about the same time as segmentation was invented, Intel was also looking at making the program counter decrement. This would help with top down software design.

Why indeed?

There are packages out there that allow numbers to be large numbers of bits long. There are also some that keep track of the number's value symbolically so 3*pi is remembered as 3*pi not 9.something.

This should be enough for all practical purposes.