ASM Community

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:
:alright:

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.

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

The new IA-64 architecture is not compatible with the previous systems. Is it right?
What are the cons and pros of IA-64?

(Awww Bogdan, you didnt play with 6502/6510? :tongue: )

omg that instruction set is terrible !!
I agree with Ultrano :)

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 :-)
Cheers,
Randy Hyde

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...

Mainframes, minis (workstations), and even Macs!
Cheers,
Randy Hyde

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 ;).

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:-

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):-
AL,AH,AX,EAX,RAX
BL,BH,BX,EBX,RBX
CL,CH,CX,ECX,RCX
DL,DH,DX,EDX,RDX
BP,EBP,RBP
SI,ESI,RSI
DI,EDI,RDI
SP,ESP,RSP

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):-
BPL, SIL, DIL, SPL

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.

Pointers
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):-

MOV RBX,ADDR MyString

which is similar to its 32-bit equivalent:-

MOV EBX,ADDR MyString

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.