Isn't the Stamp 16-bit, since it always chews on 16-bits of data at a time? If not, what determines the "bits" of a processor?

The Stamp that we're using is based on a Scenix SX28AC microcontroller which is an 8 bit unit. Typically when someone refers to the "bits" of a processor it is referring to the maximum size of integer that the processor can operate on. What this means is that, at the assembly language level, an 8 bit processor can only perform operations on 8 bit numbers. So the assembly level "add" command on an 8 bit controller can only add 2 8 bit numbers. However, you can still do 16, 32, or whatever bit math by operating on the numbers in 8 bit quantities. So if an 8 bit processor wants to add 2 16 bit numbers, it first adds the lower 8 bits of the two numbers then adds the upper 8 bits of both numbers plus the carry bit from the previous operation. I hope I'm making sense here as I can tell I'm not explaining it very well.

Anyway the bottom line is when the Stamp works with 16 bit values it is really being translated into a series of 8 bit operations inside the microcontroller running the stamp interpreter.

It is? Last I checked, PHP, C++ and Java all had IF / ELSE / GOTO control structures... Besides, programming is 90% about high level logic and 10% about syntax. A *good* programmer isn't limited by the language they have in front of them. They can think logically about the problem, come up with a solution, and then translate that solution into whatever syntax they have.

PBasic isn't bad. At least it's not raw assembly.

Ah, that makes sense.
What would the resultant of this be, does it overflow, whats the actual resultant though in binary?

01001010 10011101 +
11001010 10100101
^^
20010101 01000010
1 00010101 01000010
00010101 01000010
... any ideas? I haven't had time to look this up. The question always comes up when I'm away from my computer.

Yes, it will overflow. However, as far as I know there is no program-accessible carry bit that will let you know when this happens. Instead, you will just get the last 16 bits back and that first 1 will be lost.

hrmm, "you just get the last 16 bits back and that first 1 will be lost"...numbers are better, binary is right to left, don't you mean the "first 16" and "last 1?"

Sorry, my question was for C++ (or binary standard), which I did not state. I was mainly wondering about how - signs are stored in binary.

It all depends on what you define as first and last. I was assuming the normal left-to-right reading order. I probably should have said you get the 16 least-significant bits and loose the most significant.

Negatives in binary: two's complement. Basically, invert everything, add 1. For example, to find -1, take 00000001, invert the bits (11111110) and add 1 (11111111). This can either be interpreted as 255 or -1.

" (11111110) and add 1 (11111111). This can either be interpreted as 255 or -1." Only in PBASIC

Rbayer, notice "Sorry, my question was for C++ (or binary standard)," "how signs are stored in binary."

Hence, a 16 bit integer = 32767 through -32768.

or an unsigned short int which maxes 65535 (16 bits)

which leads me to believe that there is an actual extra bit for signs when compiling in c++.

nevermind, trying to explain my question I figured it out.

00000000 00000000
^ the 32768 (16th bit (n^(16-1))) or the last bit is used for signs.

11111111 11111111 = 65535

65535 + 1 = 00000000 00000000

in signed ints,

11111111 11111111 = -32768
01111111 11111111 = 32767

All of them off counts as the number 0, I think the last one signifies negative and has the value of 1.

ex: 10000000 00000000 = -1, considering 0 is never negative. That's why you get the -32768 instead of -32767

I think this makes sense, correct me if im wrong.


v = (n^(n))-1 -> max unsigned bit integer
range: 0 to v

v = (n^(n-1))-1 -> max signed integer

range: -v+1 to v

This is the same for either C or PBASIC. In order to differentiate between 255 and -1, you have to tell the compiler whether you are using a char or an unsigned char. If it's a char, it will interpret it as -1. If it's an unsigned char, it will be 255. Try this:

int main(){
int myNum=-1;

printf("Signed: %d\nUnsigned: %u\n", myNum, myNum);

}

You'll see that when interpreted as signed, it prints -1, as expected. When interpreted as unsigned, it will print 4294967295, which is the largest possible unsigned int (32 1's).

Using a similar program, you can find that -32768 is actually represented as 4294934528, which is 11111111111111111000000000000000.

32768=1000000000000000.

Invert: 0111111111111111.

Add 1: 1000000000000000.

Sign extend to 32-bits: 11111111111111111000000000000000, as expected.

"Using a similar program, you can find that -32768 is actually represented as 4294934528, which is 11111111111111111000000000000000."

Note: I said short int, short ints are 16 bits. I do it in short ints, because that's what i'm use to, and I don't feel like writing 32 zeros.

from my experiences when i was 13 or so working on my C server i used short ints.

V this is my experience with them

32767
Before: 0111111111111111

32767 health + 1 health
After: 1000000000000000
-32768 poor guy

Ex: 1111111111111111
-1

-1 + 1
Result: 00000000 00000000
0

Oh, lol, I didn't realize i put
"11111111 11111111 = -32768"
I'm on 6 hours of sleep for 3 days pardon me. Didn't go sleep saturday night.

I don't see the point of the inverse and add 1 you were doing.

I'm not going to argue over this one: x86 (and most other architectures) use two's complement for representing negative numbers. Under that system, you invert all the bits and add 1. It's just the way it is. Don't believe me? Go ahead and read this.

Crap, and here I was thinking all along that the bit count of a processor was the number of bits it could use to access memory. 0x123456 vs 0x123456789abc. I guess I never did the math or never realized that 268435455 memory handles was probably enough for whatever you'd use an Itanium for.

Cheap formula for twos compliment binary: 256 + x , where256 is 2 raised to the number of bits(8 here), and x is the NEGATIVE number to be converted. I used this in a comp sci class once and it worked great.

sheer joy (or boredom)
 

See, i learned basic programming and logic being bored in the back of my math class (geometry, alg II and pre-calc) and creating games and solvers. My friends and classmates all loved me for it. Anyways, it set me up for real programming, since the TI-83 plus language was very limited, i had to come up with everything myself, except for basic if, then statements, goto, inputs, and displays. So yeah, programming is 10% knowing the language, 40% logic, and 50% luck and ingenuity.

-Anthony

I am a former PBASIC hater, now reformed.
While it has its limitations, with clever programming you can do just about anything. GOTOs and all, it's still nicer than VisualBASIC. ;)

Adam