does all compiler , compiler source to assembly or machine language (0-1)?
maybe some EXE files cann't run on AMD Processors (EXE was make in Intel)?
are assembly codes faster than VC codes (same Process)?
are assembly codes optimizer that other Compilers?
Posted on 2003-12-29 20:19:47 by AliMH
Yes all compilers generate ASM code at some time...as you say hardware ONLY knows about a series of 0's and 1's :)

Everything you see/hear on your computer is made of 0's and 1's

Some languages (like .Net or Java) might generate intermediate code that will be compiled to ASM on the destination machine by a JIT (Just in Time compiler)

But finnaly to be executes ALL code must be translated to machine code in a way ot another: either compiled or interpreted.

CPU only knows/understands ASM no C++ yet :grin: AFAIK there are some FORTH based CPU's in production.

The fact that an EXE was made on Intel is of very little importance, one CPU can generate code for many other CPU's

What matters is if the AMD/INTEL CPU's are compatible with eachother (yes they are pretty much)

And/or if you did used dome specific features aka SSE2 on Intel or 3DNow on AMD, ckecking for this features has to be done at runtime by you code and YOU must act acordingly no matter if you are using ASM or C++

To you great surprise NONE of the MODERN C++ or Java compilers or HLL actually make use of the new instructions in today CPU's
(besides Intel C++ compiler and that in a strange way).

Most of them generate code for Pentium2 at a maximum :grin: without you taking very special actions (toady when Pentium 4 is in use)

So the first language that will give you the power of specific new instructions
in modern "hot" CPU's is ASM, unfortunately C/C++ comes seccond here

Well written ASM code beats VC Compiler c++ code by 2x up to 10x in speed/size, wrong written ASM code can be even slower than C/C++.

All optimizations available to C compilers are available to humman mind also
However Humman mind can usually find optimizations that a C++ compiler can never do.

Either general or even more important because mind knows the algorithm is using and the compiler can not know that info no matter what.
Posted on 2003-12-29 21:27:22 by BogdanOntanu
recent VC versions can generate SSE code too...
Posted on 2003-12-29 22:42:22 by f0dder
To f0dder:

Interesting ... what version of VC/options ? :grin:
Posted on 2003-12-29 22:48:34 by BogdanOntanu
Can't remember if vs.net has it, or if it was only introduced in vs.net2003. Option: /arch:<SSE|SSE2> . Dunno how optimal the code generation is, but I suppose it's better than normal x87 float.
Posted on 2004-01-02 14:19:45 by f0dder


CPU only knows/understands ASM no C++ yet :grin: AFAIK there are some FORTH based CPU's in production.


CPU only know machine code (0 or 1). CPU don't know ASM (xor ...). Only Assembler know ASM (mov ...). Program written in ASM (mov ...) must be assembled with Assembler to machine code (0 or 1) in order for CPU to understand what it should do.
Am I right.:confused:
Posted on 2004-01-22 16:45:18 by QS_Ong
Actually, the CPUs process the instructions at the granularity of bytes (or larger) - not bits. The mneumonics (NOP, MOV, etc...) are just symbolic forms for the numbers (90h = "NOP"). The processor does not know what NOP is, but it does know what 90h is.
Posted on 2004-01-22 16:58:14 by bitRAKE

Actually, the CPUs process the instructions at the granularity of bytes (or larger) - not bits. The mneumonics (NOP, MOV, etc...) are just symbolic forms for the numbers (90h = "NOP"). The processor does not know what NOP is, but it does know what 90h is.

CPU don't know byte, word or double word. Only assembler or compiler know. Data send to CPU through mother board data bus in 0 or 1 format, not 90h. This data received by CPU through CPU data pin eg D1, D2, D3 ... D32 for 32bit CPU. And this D1, D2, D3... only know 0 or 1. Number 90h is sent to CPU in 10010000, not 90h. And the instruction decoder will decode 10010000 and execute the job. 90h and NOP is only for humen being easy to read & understand, not for CPU.
Correct me if I wrong.:)
Posted on 2004-01-24 06:58:45 by QS_Ong
90h is just another way to write 10010000, it's the same number.
Technically the CPU doesn't see 10010000 either, it sees 0v or +1.5v or something like that, for each 0 or 1... It's all the same information, just a different way of representing it.
Posted on 2004-01-24 08:50:57 by Henk-Jan