Author Topic: Gears updated ^_^  (Read 14407 times)

halkun

  • Global moderator
  • *
  • Posts: 2097
  • NicoNico :)
    • View Profile
    • Q-Gears Homepage
Gears updated ^_^
« Reply #25 on: 2004-12-31 04:04:30 »
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.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Gears updated ^_^
« Reply #26 on: 2004-12-31 04:31:26 »
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

Qhimm

  • Founder
  • *
  • Posts: 1996
    • View Profile
    • Qhimm.com
Gears updated ^_^
« Reply #27 on: 2004-12-31 04:36:41 »
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).

sfx1999

  • *
  • Posts: 1142
    • View Profile
Gears updated ^_^
« Reply #28 on: 2004-12-31 04:55:34 »
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.

Qhimm

  • Founder
  • *
  • Posts: 1996
    • View Profile
    • Qhimm.com
Gears updated ^_^
« Reply #29 on: 2004-12-31 12:31:12 »
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.

Cyberman

  • *
  • Posts: 1572
    • View Profile
Gears updated ^_^
« Reply #30 on: 2004-12-31 15:50:04 »
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

sfx1999

  • *
  • Posts: 1142
    • View Profile
Gears updated ^_^
« Reply #31 on: 2005-01-01 03:59:40 »
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?

Micky

  • *
  • Posts: 300
    • View Profile
Gears updated ^_^
« Reply #32 on: 2005-01-01 09:38:14 »
Quote from: sfx1999
Does anyone know why my long double was 96-bit?

Maybe to align it to the next 32-bit boundary?
Quote
Also, how would we implement a long long? Would it be a template or something?

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.

sfx1999

  • *
  • Posts: 1142
    • View Profile
Gears updated ^_^
« Reply #33 on: 2005-01-02 22:22:34 »
Quote from: Qhimm
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.


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.

Qhimm

  • Founder
  • *
  • Posts: 1996
    • View Profile
    • Qhimm.com
Gears updated ^_^
« Reply #34 on: 2005-01-02 22:26:46 »
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).

sfx1999

  • *
  • Posts: 1142
    • View Profile
Gears updated ^_^
« Reply #35 on: 2005-01-02 22:58:00 »
Oh I see. I thought it sorted them so you could draw them front to back. I was wrong.