When 64-bit processors become redily available, does that mean that 32-bit assembling will become obsolete?? does it mean that we'll have to learn 64-bit assembler or perhaps C++ 64-bit edition?

i'm new to programming and so i want to make sure if i invest my time in learning assembly, i won't be doing it in vain (when considering the long term) because there is a lot of time needed to understand how to use assembly as opposed to c++ ...

your insights would be greatly appreciated

Posted on 2003-12-28 23:29:39 by quaze
imho, changes won't be so drastical. They'll happen, but in a very very long timespan. If you learn x86 , you'll be able to learn the new asm in a few days max. C++ coders won't feel the change at all - they'll have only another datatype - "dlong" maybe, and if they ever used UINT64, their code will run faster. I'm not sure about the fpu, but as those new cpus support x86, too , I think code won't change drastically (like jumping/falling from x86 to motorola).
So, relax and enjoy the ride :grin:
Posted on 2003-12-29 02:52:29 by Ultrano
Many of us already have the 64bit version of masm's compiler , ml.exe version 8, and are just waiting for an excuse to buy a 64bit processor ourselves :tongue:
Posted on 2003-12-29 05:52:51 by Homer
I agree with Ultrano in the way that if you know the 'base language' you can migrate more fast to the new language, I remember after reading some oop things, I decide to stik with C, then I find somewhere a very good tutorial on C++ and all that I know for C++ I learned in 1 day ;).

So learn 32bits-asm and you can get the idea more fast on 64 bits, and like say EvilHomer2k, you probably in this moment dont have a 64bits procesor, then practice with a 32bits processor, and when you have a 64 bit processor, practice in it!!!.

Yes lear asm32 it will not be in vain.

Have a nice day or night.
Posted on 2003-12-29 09:58:36 by rea
Is the asm syntax the same with a 64-bit compiler though?
Posted on 2003-12-29 18:03:06 by quaze
The syntax for AMD64 is "exactly" the same as 32bit

Only there are more registers R0-R16 and use REAX in instead of EAX, of course some new nstructions exist but be happy ... i think on 64bits ASM will be evem more powerfull than it is today on 32bits.

The CPU will be able to execute the 32bit code exactly as 32bits CPU can execute 16bit code , So there will be 64>32>16 in the same CPU

So no big deal about syntax, and i am also working to an assembler compatible with MASM/TASM that will use the same syntax for 16/32/64/whatever :)

Besides understanding ASM means having more knowledge.

Having more knowledge is never a minus, It is ALWAYS good

It was quite a help for me in understanding all HLL programming languages and their pitfalls.

I know ASM, C,C++,Visual Basic, Visual Fox,Forth, Pascal, Delphi,Prolog,Lisp

And ASM never hides me anything (not include HLA) while all other languages lie (besides FORTH)
I guess in a stupid hope to make you understand things faster. Knowing without knowledge its a funny ideed that hunts Earth today.

The slow learning of ASM is a myth.

Taken from ZERO (aka with no pre C/HLL propaganda) i can learn everybody/anybody ASM in about 30minutes no matter what CPU/syntax. Ask Eugen who have learned from me :P

Of course if you mind is cluttered with C++ and other HLL and propaganda it will take a little longer to take this off your head... and you might not want to.

I know ASM on this CPUs:8080,8086/80386/80485/Pentium1,2,3,4/Intel/AMD,
Z80 Z8, Z8000, 80C59, some bit slice TI and NS, Motorola 6804,68000,680020,680030

And i never had any problem learning them because i know ASM CONCEPTS, not exact syntax (that comes in time)

Just the same as in C/C++/HLL i know the HLL CONCEPTS and when i need exact syntax i (rarely) RTFM :grin:

So if you want to pretend you know something and or be "in the trend" and or make a sucessfull career and make a lot of money then learn C++/Java/.NET or whatever is today's "image of sucess"

You know:
"In order to have sucess one must always project an image of success" :grin:

But if you seek knowledge and absolute truth then go with ASM.

However this might not be the path for you :P
Posted on 2003-12-29 21:04:54 by BogdanOntanu

or whatever is today's "image of sucess"

Hehe... "today's image of success". C/C++ has been here for a while, and will be here for a while.
Posted on 2003-12-29 22:40:24 by f0dder
The new IA-64 architecture is not compatible with the previous systems. Is it right?
What are the cons and pros of IA-64?
Posted on 2003-12-30 05:09:36 by Vortex
What I learnt from google is that Intel made a cpu that isn't compatible with x86. :rolleyes:
Either they were naive, or they wanted to really try what would happen. :notsure:
AMD meanwhile created x86-64, which is completely compatible with our x86 code :cool: , running at full speed! I didn't find what has happened for some time, but now I see Intel understood they can't make everybody in the world start recompiling or rebuilding their software just to use that parallel processing thing. That parallel processing imho is kind of present in AMD's current cpus, I optimize/use such stuff.
So, Intel ate their fist and their lazy option was to get license from AMD about that AMD64 system (x86-64). So, Intel are now building a cpu Yawmill (pronounced "Yawn" "meow" I think :grin: jk).
So, our code is safe, and my optimizations too :grin:

Long live AMD :alright:
Posted on 2003-12-30 06:05:28 by Ultrano
(Awww Bogdan, you didnt play with 6502/6510? :tongue: )

omg that instruction set is terrible !!
I agree with Ultrano :)
Posted on 2003-12-30 06:31:57 by Homer
Outstanding opinions from undoubtedly the most wisest programmers this world has to offer.

Thank you for your insightful opinions ... Please keep them coming :)
Posted on 2003-12-30 23:11:35 by quaze
It took ten years (1985-1995, the epoch was the release of Windows 95) before people stopped writing 16-bit DOS code and started writing 32-bit code, en-masse. Don't expect the transition from 32-bits to 64-bits to happen any sooner. The problem with the transition is that it will be a decade before everyone has a 64-bit processor (and a 64-bit OS!) on their desks. And people who write software, except for certain niche markets, aren't about to give up the mass market for dubious performance improvements.

95% of the world's applications aren't going to be improved by going to 64 bits. The main feature of the 64 bit processors is that they break the 4 GB/process barrier. Outside of video editing, databases, and a few other specialized application, few apps need more than 4GB (or anywhere near that much, for that matter).

Sure, the 64-bit CPUs have a few new instructions; but few programmers use all the existing 32-bit instructions. It's not like those extra 64-bit instructions are going to make that big of a difference.

And HLLs, where most software is written today, won't be able to make much use of the advanced 64-bit instructions (though, with the use of large pointers, they can take advantage of the extra memory; do expect lots of programs to break in the 32->64-bit transition, as happened in the 16->32-bit transition, though).

Personally, I'm waiting for the 256-bit processor :-)
Randy Hyde
Posted on 2003-12-31 00:05:24 by rhyde
Some of us in the mainframe world have been working on 64 bit machines for several years now:

Posted on 2003-12-31 10:57:43 by S/390
I still think 64-bit processors are silly for normal workstation use. And it's not like most apps can benefit from 64bit datatypes anyway. Imo, intel did the right stuff in breaking free from x86 - that architecture is so hopeless, really, and should have been abandoned far ago. Too bad AMD are such a bunch of bigots, but I guess that's what you get from people who can't design their own stuff and have to copy other peoples architecture...
Posted on 2003-12-31 12:46:30 by f0dder
Originally posted by f0dder
I still think 64-bit processors are silly for normal workstation use. And it's not like most apps can benefit from 64bit datatypes anyway.

I remember almost this exact same quote when we transitioned from eight-bits to 16-bits and from
16-bits to 32-bits!

Imo, intel did the right stuff in breaking free from x86 - that architecture is so hopeless, really, and should have been abandoned far ago. Too bad AMD are such a bunch of bigots, but I guess that's what you get from people who can't design their own stuff and have to copy other peoples architecture...

Of course, they thought the same thing when they created the iAPX-432 architecture to replace the x86 architecture. Let's see a show of hands: how many remember the iAPX-432?

I'm not suggesting the IA-64 will die, but whether or not it will succeed is still a very open question. I agree that Intel probably made the right move for the long term; but the x86 has defied all predictions concerning longevity in the past. It remains to be seen if 64 bits is the end of the road.

Of course, the big problem with the IA-64 is that if you're going to give up x86 compatibility, why go with an Intel offering? (And Intel has finally admitted that the IA-64 is *not* IA-32 compatible when they admitted that *software* emulation of the IA-32 on the IA-64 is *faster* than the built-in hardware emulation :)).

Randy Hyde
Posted on 2003-12-31 14:35:54 by rhyde

Some of us in the mainframe world have been working on 64 bit machines for several years now:


Mainframes, minis (workstations), and even Macs!
Randy Hyde
Posted on 2003-12-31 14:38:01 by rhyde
Personally I'm glad to see that Intel gives up a legacy of x86, because x86 was developed (if I'm not wrong) in 1977 (8086 processor in 1978) and lots of things are really different in these days (protected mode from 286, 32 bits from 386, optimizations...). I believe somebody has to set up new platform after x86 and I think IA-64 is really stronger than x86, even than AA-64 (AMD x86-64).
Don't beat me, AMD guys ;)
Posted on 2004-01-02 15:48:02 by MazeGen
I admit the IA-64 has strong points, but did you ever see its instruction set? "mamma mia" I say. It's even worse than those C coding competitions where unreadability is most important. Did you see the asm code to do "dwArray1[5]=x"?
If IA-64 gets major percentage of the market, I'll get a Mac and throw my PC from the 10th floor. Or I'd never code in asm for it. Of course, it's just my personal opinion ;).
Posted on 2004-01-02 16:35:21 by Ultrano
yeah, BogdanOntanu is right, it is the concept, not the syntax :) where it may be confusing or diff architecture it is still the same.
BogdanOntanu, it is time to learn ARM now :D to make the resume bigger:P
Posted on 2004-01-02 16:59:56 by wizzra
I opened a thread "looking ahead to 64-bit assembly" in the GoAsm Assembler and Tools forum. This was solely in the context of windows programming for which GoAsm was written.

Here is an edited version of my post:-

Although GoAsm64 is some way ahead, here are some 64-bit issues as I see them in the context of assembler programming for Windows.

The 64-bit processor concerned
I have concentrated on the AMD64 processor, as a logical first step for GoAsm64. Intel have a X86-64 type chip in the pipeline, and hopefully it will have a similar register make-up to the AMD64 and use the same instructions (but will it support 3DNow!?). If there are significant differences, then we are all in trouble.
Anyway, for the AMD64 to work in 64-bit mode, it requires a 64-bit operating system. It appears that in due course, a new version of Microsoft's XP64 (codenamed "Anvil") will become available for this processor. The existing and published XP64 which now ships with Itanium based machines also has a compatibility mode, which can run 32-bit Windows programs by software emulation. It's not clear to me whether the AMD64 would require software emulation to run 32-bit programs when running under a 64-bit operating system or whether such programs could be run more directly.
The AMD64 can also run in 32-bit mode, using a 32-bit operating system such as XP. This is called "legacy mode". In legacy mode, the processor is not working to its full capacity. For example, the stack remains at 32-bits and none of the processor register extensions are available for use.

Using the same source script for both 32 and 64-bit versions
Assembler programmers will probably want to make two different versions of their programs, one for 32-bit operating systems and XP64 compatibility mode, and one for 64-bit operating systems. Preferably the same source script would be used in each case. For some time Microsoft has been planning towards this and has introduced some new switchable data types which it has recommended for use. These data types appear in various structures in the header files in the SDK. These are then switched automatically to the 64 bit versions by using #define _WIN64.
The same system can be used in assembler to make sure structures and data sizes are correct when assembling the 64-bit version. The assembler would also need to change the default size of various instructions such as PUSH, POP, CALL, JMP, Jxx, and LOOPxx. The simplest way to switch these would be for the assembler to switch to 64-bit mode if it sees (for example in GoAsm) the #define _WIN64 switch at the top of the source script, or in the command line using /d _WIN64 (probably GoAsm would not insist on the leading underscore, and would also recognise simply WIN64 or maybe WP64 as used by some Microsoft tools).
This seems to be a better solution to the switching issue than switching specific instructions, (for example switching from PUSH to a pseudo-mnemonic PUSHQ using #ifdef or #ifndef).

Calling the correct APIs
It seems from information available on the MSDN, the APIs will still be available in DLLs for programs to call. This quote is from the XP 64 FAQ's:-
Developers with 32-bit Windows skills will be comfortable and productive creating the next generation of application for Windows XP 64-Bit Edition. Developers will find the development environment virtually identical to the development environment for 32-bit Windows; the Microsoft Win64 application programming interface (API) is the same as the Microsoft Win32? API. The existing APIs have been modified where necessary to allow them to reflect the precision of the platform on which they are running. The result is programming simplicity and a short learning curve for the developer?writing code for 64-bit Windows is just like writing code for 32-bit Windows.

It seems that in XP64 the APIs have the same names as those in 32-bit XP and even have both Ansi and Wide versions as before. Clearly though, they act in quite different ways, since they will be working with 64 bits of data sent to them on the stack and not 32 bits. It seems from the above quote that the API switches into 64-bit mode if the caller is a 64-bit program. This would appear to be the simplest way to achieve the required result - for program development anyway!

Identifying the new 64-bit registers
Here I have followed the names used in the AMD64 manual:-
The general purpose registers, (as extended to 64 bits):-

The low-bytes of all the general purpose registers (first 8-bits) are now addressable. The syntax could be (as suggested in the AMD64 specs):-

The new general purpose registers (64 bits). Since the first 8, 16 and 32-bits of these are addressable (as well as the whole register), some way needs to be found to distinguish between these. The AMD64 specs suggest:-

The first byte of each register - R8B to R15B
The first word of each register - R8W to R15W
The first dword of each register - R8D to R15D
The whole register - R8 to R15

The MMX registers (64 bit) - MM1 to MM7

The floating point registers (shared with MMX) - ST0 to ST7

The XMM registers (128 bits) - XMM0 to XMM7

The new XMM registers (128 bits) - XMM8 to XMM15

More data mixed up with code?
The AMD64 makes use of RIP-Relative addressing. RIP is the new 64-bit instruction pointer (it replaces EIP). The AMD64 processor can read data at an address relative to the RIP at any one time using an 32-bit offset value. Up to now relative addressing was only used for jumps to a new instruction place. For this to work, it probably makes no difference to the processor whether the data is in executable or non-executable areas and the processor may in fact be blind to this. Since RIP-relative addressing could shorten code considerably (no need for large displacement values to be included in the instruction) the assembler will need to use it as much as possible. There is probably a lot of scope here for optimisation either automatically or manually.

These point to a particular place in memory (they are an address of something in memory). In 64-bit mode all pointers will be 64 bits, whereas in 32-bit mode they are 32 bits. In practice, I don't think this will matter much. For example in 64-bit mode to put the address of a particular string (labelled "MyString") into RBX you would use (GoAsm syntax):-

which is similar to its 32-bit equivalent:-

New instructions
There are only a handful of new instructions required.

Net gloom
There has been a lot of gloom in earlier threads about Longhorn, and Microsoft's apparent wish to envelop us all in .net fog in due course. To my mind, Microsoft will be ensuring that current Windows executables will work on future machines and Windows operating systems. That must mean that the API's will always be available in DLLs even if in the far future this works through some sort of wrapper. If this is right it means that Windows assembler programmers will be able to continue to program normally into the far future. Also I believe 32-bits will not just disappear. Many applications will work perfectly well in 32-bits, even under future 64-bit systems (and I am not talking about Itanium). They will not need the extra power available from 64-bits.
Posted on 2004-01-03 03:37:42 by jorgon