Are we going to 64 bit Assembly?

[frktons]

It depends on the chip and motherboard.. the architecture itself is capable of addressing 2^64 bytes of memory even if the hardware isn't..

...much like the first 80386's couldn't be loaded with 4 gigs of ram (4 megs was probably your max) that in no way means that the architecture didn't support it. It just means that those address lines werent connected to anything.

Yes Rockoon, we are not fully using 64 bit so far, but we are going that way I guess.

You never used a C/C++ compiler, did you?

Code Select Expand


When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one

That's so funny, I'm just learning C for the time being.  :P

[Rockoon]

When C++ compilers can be coerced to emit rcl and rcr, I *might* consider using one

That's so funny, I'm just learning C for the time being.  :P

That jab is specifically at C++ "intrinsics" ..

C/C++ fanatics first claim that their compilers are better than ASM programmers, and when shown that this isnt true (as is easily demonstrated with even sloppy SIMD code), they claim that intrinsics extensions in the various compilers put them on a better footing with SIMD than the C++ standards themselves would allow

So I am pointing out that am still unaware of any C++ compiler than will ever emit an RCL or RCR instruction under any circumstances other than with actual inline assembler. No RCL or RCR intrinsics are possible because there is no concept of a 'flags' register in the C/C++ abstract machines, and no C/C++ expression can clue the compiler in enough to leverage RCL or RCR either.

I dont use C/C++ because there is always a better choice for my needs. For RAD it was VB6, and for one-off computations its been VB.NET console applications.. all can be augmented with ASM. I use ASM for libraries, not applications. C/C++ doesnt buy me anything I need.

[frktons]

That jab is specifically at C++ "intrinsics" ..

C/C++ fanatics first claim that their compilers are better than ASM programmers, and when shown that this isnt true (as is easily demonstrated with even sloppy SIMD code), they claim that intrinsics extensions in the various compilers put them on a better footing with SIMD than the C++ standards themselves would allow

So I am pointing out that am still unaware of any C++ compiler than will ever emit an RCL or RCR instruction under any circumstances other than with actual inline assembler. No RCL or RCR intrinsics are possible because there is no concept of a 'flags' register in the C/C++ abstract machines, and no C/C++ expression can clue the compiler in enough to leverage RCL or RCR either.

I dont use C/C++ because there is always a better choice for my needs. For RAD it was VB6, and for one-off computations its been VB.NET console applications.. all can be augmented with ASM. I use ASM for libraries, not applications. C/C++ doesnt buy me anything I need.

Well, I've heard something like compilers are better than programmers, but I didn't buy it.  :P
This is an old, unsolvable debate that I don't like to join anyway.

I had the idea that interfacing C and MASM was one of the preferred way to get system job
done, and easily done as well. ::) These two languages are supposed to interface easily with each other.

I'm a bit curious, if you don't mind,  about what language you are using to interface Assembly
and how easy/productive this mixed language programming is in your opinion.

[TASMUser]

I think you are crazy if you thirst for 64biz.
The only reason for to be dead keen on 64biz can only have one reason: the disability to develop reasonable algorithms in the environment which is given.
See the "C" programmers some years ago: at that time they cried for 32bits because they were unable to declare unsigned 16bit values in there overloaded inefficient "C" programs.
Nowadays these same stupid "programmers" are unable to manage the meanwhile very versatile contrived 32bit environment so they cry for the next 64biz hop. And all these stupid gamerz will confirm this rule...

[frktons]

I think you are crazy if you thirst for 64biz.
The only reason for to be dead keen on 64biz can only have one reason: the disability to develop reasonable algorithms in the environment which is given.
See the "C" programmers some years ago: at that time they cried for 32bits because they were unable to declare unsigned 16bit values in there overloaded inefficient "C" programs.
Nowadays these same stupid "programmers" are unable to manage the meanwhile very versatile contrived 32bit environment so they cry for the next 64biz hop. And all these stupid gamerz will confirm this rule...

I'm learning C and Assembly, and I use a X64 bit machine with a win7 64 bit.
I guess it is natural to think about 64 bit. The C compiler I use "Pelles'C" is a
64 bit compiler, so while I learn I also ask myself what are the differences, and
why if I compile a C program in 32 bit mode it is slower than the same C
program compiled in 64 bit mode?

By the way, I am neither crazy nor thirsty for 64biz, just naturally curious.  :P

[hutch--]

 :bg

Frank, in answer to your original question YES but don't hold your breath waiting. Its like watching paint dry and well written 32 bit is fast.

[jj2007]

well written 32 bit is fast.

In fact, there seem to be very few cases where 64-bit code beats 32-bit code. I wonder what is the role of the code and memory caches in this.

[frktons]

:bg
Frank, in answer to your original question YES but don't hold your breath waiting. Its like
watching paint dry and well written 32 bit is fast.

Thanks Hutch. Of course it's better to breathe.  :U
Fortunately enough I don't have to code anymore for living, and I keep a relaxed attitude
towards IT stuff, and learning for FUN.
Time is short, neurons are fewer than once, so I like to go slowly trying to make faster
code. What a nonsense  :lol  :P Really funny, worth doing  :8)

In fact, there seem to be very few cases where 64-bit code beats 32-bit code. I wonder
what is the role of the code and memory caches in this.

Me too, I'd like to understand why the few progs I compiled in 64 bit mode with
Pelles'C compiler are about 20% faster than the same progs compiled in 32 bit mode ::)
Those are C program by the way.

[redskull]

I wonder what is the role of the code and memory caches in this.

If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.

-r

[jj2007]

I wonder what is the role of the code and memory caches in this.

If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.

-r

That's my theory, too. Unfortunately, I can't test it :bg

[MichaelW]

If everything but the cache is twice as big...

[Antariy]

I'm learning C and Assembly, and I use a X64 bit machine with a win7 64 bit.
I guess it is natural to think about 64 bit. The C compiler I use "Pelles'C" is a
64 bit compiler, so while I learn I also ask myself what are the differences, and
why if I compile a C program in 32 bit mode it is slower than the same C
program compiled in 64 bit mode?

Frank, if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done. As 16bit progs run slow on NT (and hang Win9x :), 32bits run slightly slow under 64bits OS, too.

Alex

[frktons]

Frank, if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done. As 16bit progs run slow on NT (and hang Win9x :), 32bits run slightly slow under 64bits OS, too.

Alex

Thanks Alex for the explanation. This have to be one of the reasons X64 bit machine and 64 bit OS
like more 64 bit applications.  :lol

[jj2007]

if 32bit app runs on 64bits OS, it work on Wow64 subsystem. This subsystem implement mechanism, like Wow16 subsystem on NT's, or thunking mechanism in Win9x. I.e. - translate calls to system to 64bits requests. So, this take some performance to be done.

Very well explained, thanks Alex. Of course, the marketing will say "look, 64-bit apps are faster" - and you cannot prove the contrary because you cannot make a 64-bit app run on a 32-bit OS.

I wonder if this comparison would be valid, for the same identical 64-bit processor:

xx cycles for App32 on OS32
xx cycles for App32 on OS64
xx cycles for App64 on OS64

[Rockoon]

I wonder what is the role of the code and memory caches in this.

If everything is twice as big, an equal sized cache holds half as much, and misses twice as often.

-r

but all things arent twice as big on the AMD64 design (which intel also uses)

The native machine word is still 32-bit. It is only pointers that have been forced larger.

So some data structures, such as pointer heavy linked lists and trees, are negatively effected, while others.. like hash tables and other pointer-less structures, arent effected at all.

32-bit programs recompiled (that is, using a compiler) for 64-bit are usually faster because there are over twice as many registers for the compiler to work with. Thats a big win in non-trivial algorithms which otherwise would be moving local variables to-and-from L1 a lot.

WOW64 doesnt add much overhead. All that overhead is on folder virtualization (redirecting /system32 to /syswow64) .. the overhead is in front of slow disk operations so really cant be effectively measured without writing code so absurd that it would never pass a code review.

The meaningful negative effects are all about the larger pointers.