unsigned, char, int, long?

[Inner]

More of a question that a feature request, but why is that only signed data types ? just wonder what the logic is behind this? otherwise I am going to have to resort to a 1mb executable, by making a userlib for GFL because PB can't cope with data types needed to access the library, does beat the crap out of me as too why, but I am sure there is a good reason.

[Fred]

You can use unsigned right know with a little trick. What's your problem exactly ?

[Inner]

okay, so what's the little trick? StrU()?

well that isn't going to work to well,

DibInfo\bmiColors\rgbRed=Val(StrU(*ColorMap\GFLCMRed,#Byte))

The colormap\gflcmred will have an unsigned char, the exact clone of which has to be copyied into the DibInfo\bmiColor\rgbRed . however when you real the Colormap structure this value if it happend to be 255 will = +127, thus StrU() except it has to be a value not a string, so that it can go back to Dibinfo structure, to it's converted back to a Val() this works too a point. I'm not entirely sure why, but on some GIF images it corrupt the image palette.

besides this, why do we need a trick?

I'm just trying to understand the logic behind it that's all for an example of my way of thinking, I'd have had

signedbyte.b
signedint.i
signedlong.l

and

unsigned.ub
unsigned.ui
unsigned.ul

there wouldn't be any confusion when porting/converting DLL files, because you'd be using the exact same data type the DLL .h file is using, and no need for conversions either.

[Fred]

Mixing unsigned and signed is not as easy as it looks and the first PB version was supporting them. But with the tons of performance issues/problems I've encounter, there are now gone.

About your stuff, just use:

DibInfo\bmiColors\rgbRed=*ColorMap\GFLCMRed & $FF

and it will be ok.

[Inner]

thanks, fred.. now the madness means a little sence

[matthew180]

Mixing unsigned and signed is not as easy as it looks and the first PB version was supporting them. But with the tons of performance issues/problems I've encounter, there are now gone.

You're going to have to explain this one. The only difference between signed and unsigned is the way the bytes are treated by certian operations and the user. For example, you use IMUL/IDIV instead of MUL/DIV for signed numbers, but I don't see where that would be a problem for the compiler to figure out at compile time (since PB keeps track of variable types already.)

In the case of trying to multiply a signed and unsigned number, you would simply do as in C or other languages, one of the number is cast to be the same as the other. As long as you 1. make the casting consistent and document it, and/or 2. allow the user to explicitly cast a variable, I don't see why this would be a problem? Everything is determined at compile time, so what are the problems and performance issues?

Matthew

[Fred]

Ok, just explain to me how you will compare signed and unsigned numbers at high speed...

[Inner]

uhmm well... er, LccWin32; didn't mind..

//
unsigned long foo=0;
signed long boo=1;

if(foo==boo)
printf("yaba daba doo");
//
unsigned char foo=0;
signed char boo=1;

if(foo==boo)
printf("yaba daba doo");
//
unsigned int foo=0;
signed int boo=1;

if(foo==boo)
printf("yaba daba doo");

--

I guess the 'programmer' has to use his head a bit. or maybe matthew180 has a better idea, I dunno.

[matthew180]

Ok, just explain to me how you will compare signed and unsigned numbers at high speed...

I'm using C and ASM because I need languages that support unsigned types in order to give examples.


First, to quote the IA-32 Intel® Architecture Software Developer's Manual, Volume 2: Instruction Set Reference:

"Jcc - Jump if Condition Is Met (Continued)
The conditions for each Jcc mnemonic are given in the Description column of the table on the preceding page. The terms "less" and "greater" are used for comparisons of signed integers and the terms "above" and "below" are used for unsigned integers."

And, for a particular instruction (I chose ADD):

"The ADD instruction performs integer addition. It evaluates the result for both signed and unsigned integer operands and sets the OF and CF flags to indicate a carry (overflow) in the signed or unsigned result, respectively. The SF flag indicates the sign of the signed result."


Now, from the IA-32 Intel® Architecture Software Developer's Manual Volume 1: Basic Architecture:

"Some integer instructions (such as the ADD, SUB, PADDB, and PSUBB instructions) operate on either unsigned or signed integer operands. Other interger instructions (such as IMUL, MUL, IDIV, DIV, FIADD, and FISUB) operate on only one integer type."


Now, first of all, there is no difference between a signed and unsigned integer except for a few things:

1. How the programmer decides to treat the data.
2. How the language checks comparisons.
3. How the language does multiplication and division (in the case of IA32 architecture.)

So, basically what this comes down to for the byte, word, and long types in PB is what Jcc (conditional jump) PB's compiler chooses, and whether to use MUL or IMUL and DIV or IDIV. Now, since PB maintains the type of each variable, this should be trivial and can be (and should be) done at compile time. Also, since we are talking about using JBE (for unsigned comparisons) or JLE (for signed comparisons) or MUL/IMUL, etc. I don't understand what this performance problem is you keep talking about??? I hope you don't try to tell me that JBE executes slower the JLE, etc.???

Here is an example (see below for the actual code.) Compile these on your favorite Unix box with gcc and look at the ASM output:

gcc -S signed.c
gcc -S unsigned.c
diff signed.s unsigned.s

1c1
< .file "signed.c"
---
> .file "unsigned.c"
20c20
< jle .L6
---
> jbe .L6


If you run these you will notice that they perform as expected, with the only difference being the choice of comparison at compile time.

So, to support unsigned bytes, words, and longs, all you need to do is:

1. Allow the programmer to indicate a type:
a. var1.ub (unsigned byte)
b. var2.uw (unsigned word)
c. var3.ul (unsigned long)

2. For comparisons, make a check of the type and use the appropriate Jcc instruction.

3. For multiply or divide, make a check of the type and use IMUL/MUL or IDIV/DIV accordingly.

4. For SHR/SAR, make a check of the type and use SHR for signed types, and SAR for unsigned types.

5. It would be nice if output functions (like PrintN) would also consider the type and output accordingly.

That's pretty much it. If the programmer tries to compare unsigned to signed types you can either blow and error during compile time, treat both numbers as signed/unsigned based on some rule that you document, or allow the programmer to cast one type to the other for that operation (like in C...)


Matthew


(unsigned.c)
#include <stdio.h>

int
main(void)
{
unsigned int i;
unsigned int j;
unsigned int k;

i = -10; // <-- really 4294967286
j = 10;

if ( i > j )
k = 1;
else
k = 0;

printf("%d, %d, %d\n", i, j, k);

return(0);
}

Output: -10, 10, 1


(signed.c)
#include <stdio.h>

int
main(void)
{
int i;
int j;
int k;

i = -10;
j = 10;

if ( i > j )
k = 1;
else
k = 0;

printf("%d, %d, %d\n", i, j, k);

return(0);
}

Output: -10, 10, 0

[Inner]

matthew180 : I didn't know this was such a saw point .. maybe I should be making a bigger thing over it!.. I shall write more after tea I think.

[Fred]

I was talking about MIXING unsigned and signed numbers in expressions, comparisons and more. Doing all in unsigned is of course very easy. Think than even VC++ warns you when you do a such comparison between signed and unsigned because performances and unexpected result and ask for cast. Do you want casts be introduced in a basic langage ? Anyway, if you can give the solution, I'm will be of course very glad.

[wcardoso]

Fred:
In my humble opinion, is the programmer business who compare with who. All we need is the freedom to use signed, unsigned, float, etc. for our variables. Look at IBasic about this topic.
If PB will manage this, then there isn´t any excuse to not use PureBasic for all our projects; isn´t it ?
¡Viva PureBasic!, ¡Viva la France!

[Inner]

Ah-ho, I've opened a can of worms sorry Fred

[Karbon]

So the only reason there aren't unsigned variables is that comparison between signed and unsigned variables is slow and can lead to strangeness? It seems this is in fact a problem with unsigned numbers not really any single implementation.. As you said, even VC++ warns about signed/unaigned comparisons so why not make PB do the same thing and put the responsibility on the programmer to handle the variables properly?

Many people see the lack of unsigned variables as a serious problem with PB so adding these would shut up a *lot* of people - and extend the language quite a bit!

And as far as casting variables - why not! The more power the better! PB is already more a BASIC/C hybrid than anything else so I don't see the validity in the argument of not expanding the language because it has BASIC in it's name.. More power is better IMHO!

Thanks Fred!

[Fred]

Ok, so you kick me again in front of the paper board, right ?