Gears updated ^_^

  • Thread starter Thread starter halkun
  • Start date Start date
Status
Not open for further replies.
I just typed in halkun's code into MS Visual C++ NET and Dev-C++ 4.9.9.0. This was tested on my Laptop, a Intel Pentium III 700MHz (Coppermine-T)

error C2632: 'long' followed by 'long' is illegal
Click to expand...

char size is 1 bytes
short size is 2 bytes
int size is 4 bytes
long size is 4 bytes
Press any key to continue :D
Click to expand...

char size is 1 bytes
short size is 2 bytes
int size is 4 bytes
long size is 4 bytes
long long size is 8 bytes
Drücken Sie eine beliebige Taste . . . :D
Click to expand...

So much for that.
Oh, and I didn't want to know how you specify your integers in your programs, I wanted to know how the simple in, short and long types are defined.
Okay, thanx anyway

 - Alhexx
 
Oh, and I didn't want to know how you specify your integers in your programs, I wanted to know how the simple in, short and long types are defined.
Okay, thanx anyway

 - Alhexx
Click to expand...
Hmmm well it's compilor/archetecture dependant. No standard has been given for the format and size of the data save FLOAT and DOUBLE. Those are already IEEE standards world wide accepted and people can't twiddle them (although MS seems to have tried to several times with extended floating point types <rolls eyes>).

Cyb
 
MS did? The only thing I know of the current MS compiler is the lack of support for extended precision (80-bit floats) as used in intel processors...
 
Single precision floating-point numbers (float) are 32 bits.
Double precision floating-point numbers (double) are 64 bits (hence "double").
Extended precision floating-point numbers (no standard type name) are 80-bit. This is the size used internally for floating-point processing in x86 CPUs.

The CPUs have support for directly using 80-bit floating-point numbers in your programs, but few higher-level languages have explicit support for it. In Microsoft's case, it's actually explicit non-support; they won't implement an extended data type because there's not enough demand to rationalize the work of exposing a third floating-point precision.
 
Wait, lemme get this stright....
The x87 80 bit coprossesor functions, that has been around since 1980 on the 8087 add-on chip, has no support by Microsoft?

Even though Windows is the domninate OS on the x86?

Wow, the mind boggles at that one.
 
It's too bad there is no support for 128 bit floats. I guess the demand for those is highly limited ;)

Yes Halkun support for extended precision is a pain. Although MS DID have support for it they don't any longer.  Namely it's not needed.  I do think they support the BCD numbers however, and those are 80bits.  15 1/2 digit mantissa with the sign with a 3 1/2 digit exponent with sign.  Good for spread sheets :)

Cyb
 
Well the x87 does all its calculations in 80-bit, it just converts floats and doubles automatically as it reads from/writes to memory. The C library has special functions for the "long double" type which is basically the full 80-bit precision, but ever since the Microsoft compiler moved to Win32, "long double" is resolved to a 64-bit precision instead. The type still exists, but it has the same precision as a normal double. So, using a Microsoft compiler, there is no easy way to work with extended precision numbers. You pretty much have to write inline assembler code to do it.

Speaking of which, once the compiler moves to Win64, support for inline assembler will also be removed (God knows why). Microsoft intends to replace it with compiler intrinsics, i.e. "functions" that correspond to certain instructions but still lets the compiler handle most of the details. Anyone who ever tried using the MMX or SSE intrinsics know, however, that the code is wildly inefficient (often creates stack variables for things that could be done using only registers, etc).
 
I've heard that Microsoft's inline assembler sucked. I heard that it ran slower than C code. NOP NOP I guess.

I have just tested MinGW's size of a long double. It turns out that it is 12 bytes, or 96 bit. 96 bit? WTF? Something's not right it should be 10.
 
I quite like MS's inline assembler, mostly because it's WYCIWYG. Except for when you access C variables from within the inline assembler, you pretty much know exactly what you're getting. The problem with any inline assembler is that the seam between the high-level language and the assembler is tricky and often unoptimized (the compiler has to automatically preserve registers and such), so to get the best of it you're better off writing larger chunks of code (like an entire iteration loop, instead of only the inside of the loop).

I wrote an MMX-enhanced alpha blending loop using MS inline assembler, which, without being particularly biased towards my own code, runs faster than any other software alpha blending routine I've seen on the web. So, certainly not slower than C code, unless you code badly.
 
This reminds me of the fact that a number of people developing CODECS no longer use MS's compilor.  It seems MS thinks they know more than the programer or something like that.  It's really weird when someone compiles there once VC based application with 2 different compilors because MS 'assumed' they knew more about integer SSE, SSE, SSE2,  and MMX than the person using there compilor.  There is a big RANT about it on VirtualDub's page, and apparently he now writes the codec in C exports it as assembly then cleans out the garbage the compilor puts in it and cleans up the MMX SSE SSE2 etc.  It's a bit of a headache to say the least.

All I can say is 'Go Microsoft alienate more people' (sarcastic tone ;) ).

Seriously .. I really do not understand MS bullying techniques on optimization. What's with the 'We'll do it our way' attitude they have?  It's just, well, dismaying.

All right I've almost got the first conversion layer finished for exporting FF7 models into POV with rotation angles and variables.  However I'm pretty sure I've got the information wonky. (Cloud is still doing the splits!)

Cyb
 
Does anyone know why my long double was 96-bit?

Also, how would we implement a long long? Would it be a template or something?
 
Does anyone know why my long double was 96-bit?
Click to expand...
Maybe to align it to the next 32-bit boundary?
Also, how would we implement a long long? Would it be a template or something?
Click to expand...
Visual C has the __int64 type. My personal "types" file uses __int8/16/32/64 for visual C, and char/short/long/longlong on gcc.
 
I wrote an MMX-enhanced alpha blending loop using MS inline assembler, which, without being particularly biased towards my own code, runs faster than any other software alpha blending routine I've seen on the web. So, certainly not slower than C code, unless you code badly.
Click to expand...

OK I was thinking about this and it was killing me. Do you use a radix sort?

Then the other question I had was that if you use it to sort polygons, but use MMX, then how would you be able to sort floats? MMX doesn't have floating point support, and mixing floating point and MMX requires a couple operands and some register unloading.
 
I feel there's been some slight miscommunication here. My code only blends two pixels together based on their alpha (opacity) values. It also correctly calculates the opacity of the resulting pixel. It has nothing to do with polygons or sorting, just simple low-level color channel processing (for which MMX-style SIMD instructions are ideal).
 
Oh I see. I thought it sorted them so you could draw them front to back. I was wrong.
 
Status
Not open for further replies.
Back
Top