I doubt that there will be a radical change to the number of colors. After all let's face it, 32 bit color is not real either. The high order byte is discarded or used for alpha blending, the actual color code is still 24 bits. The real advantage is in moving and processing multiple colors at a time. With MMX you are still limited to a 32 bit bus and no matter how fast your graphics card is or how many bells and whistles it has, you still sometimes have to get rgb data to the card and there the limit is bus width.
Posted on 2003-08-26 17:12:21 by donkey

Personally I think its about time the slate was wiped clean. If it wasn't for the price I'd buy an Itanium before AMD64 anyday.

And what about your asm programs? They will be very sloooow on Itanium ;)


64 bits...
I think this will be a waste of memory in most purposes because you will have to store your data with qword alignment.
Even 32 bits are really much.

So I hope they'll make an optional 32 and 16 bit (fast) adressing.

And if you want faster graphics and sound you propably should use the GPU and SPU of your graphics- and soundcard.:grin:

Why don't they jump immediately to 128bits or more if its so much faster?;)

Operton is faster even with x86-32 code than AthlonXP running at the same frequency, because it has more optimized microOP execution core.
AC'97 with soft-syntezis killed most SPU, IMHO ;) No need to use Audigy2 if you don't have >0 speakers.

Originally posted by donkey
The real advantage is in moving and processing multiple colors at a time.
:alright:
May be CPU will kill GPU one day... If GPU will not accelerate raytracing


One of *real* Operton advantages, IMHO, is integrated DDR SD-RAM controller, with less latencies. More RAM speed at the same clocks
Posted on 2003-08-27 01:26:52 by S.T.A.S.

May be CPU will kill GPU one day... If GPU will not accelerate raytracing

I'd rather see the GPU taking over **all** GUI processing (including raytracing, scanline, raycasting, whatever graphic rendering) -- so that teh CPU can do more usefull things (such as instructing teh other specialized devices PUs). Graphics Processing requires a lot of power/calculations, the GPU are optimized for processing graphics, wheras the CPU is able to do basically everything. I think of the CPU as the coordinator of the computer, delegating tasks to other PUs/devices.
Posted on 2003-08-27 09:40:21 by scientica
Floating point color is the future.
Posted on 2003-08-27 09:48:15 by ThoughtCriminal


I'd rather see the GPU taking over **all** GUI processing ...


That is what I wanted to say above.:cool:
So that you don't have to use the CPU for this purpose:


... The real advantage is in moving and processing multiple colors at a time. ...
Posted on 2003-08-27 12:24:41 by TCT

I think of the CPU as the coordinator of the computer, delegating tasks to other PUs/devices.

... and executing Java bytecode :tongue:
Posted on 2003-08-27 19:54:02 by S.T.A.S.


... and executing Java bytecode :tongue:

Yes, since I don't think there is a big need for BPUs (Bytecode Processing Units) ;)
Posted on 2003-08-28 01:29:38 by scientica

Personally I think its about time the slate was wiped clean. If it wasn't for the price I'd buy an Itanium before AMD64 anyday.


I second that. IMHO, IA32 is crippled by the need for compatibility with IA16. (I coined IA16, so don't expect it to show up in google or elsewhere. Although Intel claims that 8086/8088 and 80286 are IA32, who believes they were 32 bit CPUs?)

Besides, anyone with Unix assembly background will immediately like what IA64 provides. I particularly like the idea of GP, which frees ebx (although IA64 does not call it ebx) for shared libraries. One person without Unix experience commented that GP register is another DOS segment nightmare. All I can say was to quote Mr. T. :tongue:

Then again, at the current stage, Itanium is known to "sensitive" to HLL compilers, giving worse performance than Pentium III in one case and outperforming Pentium 4 with almost twice faster clock freq in other case. But we are asm programmers, aren't we? :)
Posted on 2003-08-28 03:10:01 by Starless

I particularly like the idea of GP, which frees ebx (although IA64 does not call it ebx) for shared libraries. One person without Unix experience commented that GP register is another DOS segment nightmare.

What do you mean with GP? Do you mean GPR? (General Purpose Registers) or do you mean something else? :confused: :confused: :confused:
Posted on 2003-08-28 10:56:48 by scientica
The unix idea shared libs is retarded on x86, with those few GP regs on x86... what is wrong with relocs? If you have some 32+ GP registers, the idea of using a register for base is sort of okay, as you won't have to re-apply relocs when loading a clean page from disk. But for x86... it's retarded. You just can't sacrifice a global app-lifetime register for something like this.
Posted on 2003-08-28 12:24:49 by f0dder
i sucked the amd64-docs a few days ago and read through em about an hour. all these explainations make me believe that the hybrid-thingy of amd is kind of a bungle (dunno if that's the right word, i looked it up in the dictionary; in austria we'd say "pfusch" :)). it seems to make big problems to stay downward-compatible. it's a very long way to get to the real 64bit "long-mode", but on the quick overview i read that it will only support the flat memory model, they had to introduce a 4th paging-level and in the end they can "just" access 2TB (48 bits). also the V86-mode was removed for the 64bit longmode, the extended registers are just accessible in that mode also (not even in compatibility mode). they had to introduce 2 new modes just to keep downward-compatibility. but what made me stuck most is that intel-IA64-programs won't be executeable on that processor.
when i by a 64bit processor then i'll use my 64bits, where intel's solution seems to be the better one, although i initially thought the hybrid-solution would be the better one...
Posted on 2003-08-28 14:04:27 by hartyl
Getting more and more Heap material... Oh well, this thread began at the borderline, anyway.

GP on IA64 is "global pointer". Think of it as GOT/PLT pointer for shared libraries. Or, think of it as something like (e)sp or (e)bp which must be used in a special way in some context. For better and accurate description, see IA64 manual.

Let me reparaphrase f0dder.
"The unix idea shared libs is retarded on x86, with those few GP regs on x86"
should read as
"The implementation of unix shared libs on x86 is retarded".

The Unix shared library idea is superior to other shared library idea, because of the reason that f0dder mentioned, and because they can really move around in the memory after loaded (also a consequence of the reason that f0dder mentioned). But, some people *SCOugh* believed that it could be implemented on x86 by sacrificing ebx. They may deserve f0dder's criticism. What is worse, all of their decision including _errors_ (not bugs) propagate to all Unix implementation on x86.
Posted on 2003-08-28 19:58:19 by Starless
btw, i searched around in the amd64-docs to find out what the R in the register's name stands for? the E was "extended" in the 32bit registers, but i cant think of a meaning in the 64bit ones...
i like the new istructionpointer's name most "rip" :tongue:
Posted on 2003-08-29 13:20:55 by hartyl
IA64 / AMD64 !!

how write a 64-bit program for ASM?

use (.mode flat) too??

the cpu will to 64-bit ... speed will fast more...
now many hight level langue will at new 64-bit work
how use ASM at 64-bit work?

i only study ASM.. dont know other hight-level langue...
need about new ASM for 64-bit more infomation..... @.@
Posted on 2003-09-04 14:56:06 by swang
another question spinning in my head:
amd64 does everything to stay compatible with the current IA32 and that processor boots in realmode. does the real 64bit processor of intel also start up in realmode? or is it already in 64bit mode when the bootcode is executed?
i'll love systemprogramming for the IA64 if it is so.
Posted on 2003-09-06 14:05:09 by hartyl