Are we going to 64 bit Assembly?

[dedndave]

it seems like, when you double the architecture width, you need to quadruple everything else
4 times as much RAM
4 times as much disk space

[redskull]

The meaningful negative effects are all about the larger pointers.

Agreed, but high-level languages are notorious for being pointer-heavy.  C++ objects come almost exclusively from the heap, you have to use pointers to get inheritance, STL containers, etc, etc.  Lord knows how Java works, but I suspect it's pointer-centric as well.  More reasons to use ASM, of course!

-r

[frktons]

Something we should take into account is that 64 bit tech and software
are relatively new. Many things are not still stable nor optimal.
The only hope is that, being it the de facto modern tech everybody
uses or is going to use, it'll get more stable and optimal as time passes by.

People who have to take care of legacy code are going to stick to 32 bit
programming for some more years. The "free from legacy code" people
like me, can look at the future with a more relaxed attitude, hoping for
the better, and jumping from a tech to the other to have a look at what's
happening around.  :P

[redskull]

32-bit will be here for a long, long time, just for that reason: legacy DOS code.  I know several businessess (and have worked at many, too) that simply just can't upgrade to 64-bit versions of Windows, because their tangled web of software has some critical dependency on some tiny DOS program that was written by a company that's now out of business.  As long as 64-bit Windows doesn't have some easy, streamlined way to run 16-bit DOS programs (even if it's done in software), I wager it won't be adopted en masse in the business world.

-r

[Antariy]

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

Sorry, Jochen, I not very good understand you. One good man help me to understand, what you don't say sarcastic.
I don't have 64bit CPU and OS for playing, but by my work I have "touched" with many-many computers.
You remember, how "nice" you format diskette under Win9x? Because 16bit implementing of these systems is awesome.
On 64-bit OS, to 32bit program, available more than 3.5 GB of memory. This is tested on one notebook with x64 CPU and Windows 7 x64 Edition.
Prog, which allocate pieces by 25.6 MB, get 150 these pieces. So - 3.75 GB. If pieces smallest, may be allocated more.
No bad reason: give to 32bit app nearly 4GB of memory on 64bit OS, right? On 32bit systems, to app available <2 GB usually, and <3GB with /3GB switch (I mean XP and 2003).

If you can test 64bit app on 32bit CPU - you grandmaster Yoda, not less! :)


Alex

[Antariy]

About Jochen's:

.... and you cannot prove the contrary because you cannot make a 64-bit app run on a 32-bit OS.

I don't like WinAPI calling sheme on Win64. Those scheme is no good. Many actions with RSP, some demands (align of RSP) and preserving space for args before calling. For which need fastcall convention, if it make fastcall slower/equal that stdcall?

Alex

[frktons]

As with old 16 bit code, in years to come, the disadvantage of 32 bit programming
versus 64 bit programming will become more and more evident. New OSes will run
64 bit code faster and better, and the same will not be true for 32 bit. As I forecast
the market will push everybody towards 64 bit programming, no matter what.

Actually the market is pushing towards 64 bit machines and OSes. Is it that strange
that next generation programming will be 64 bit?

[sinsi]

As with old 16 bit code, in years to come, the disadvantage of 32 bit programming
versus 64 bit programming will become more and more evident. New OSes will run
64 bit code faster and better, and the same will not be true for 32 bit. As I forecast
the market will push everybody towards 64 bit programming, no matter what.

Actually the market is pushing towards 64 bit machines and OSes. Is it that strange
that next generation programming will be 64 bit?

Nope. Look at how much legacy win16 code is out there, that's why OS's come in 32 and 64 bit.
All 64-bit code is, the OS makes sure the selectors are set for long mode, the same process happens for 32-bit code except for that 1 bit.
Still have to setup the ldt, page tables etc.

64-bit is great for the extra registers and an assumed minimum level of SSEx as well as the address space.
The calling convention for win64 is ludicrous though...as I always complain  :bg

[frktons]

Nope. Look at how much legacy win16 code is out there, that's why OS's come in 32 and 64 bit.
All 64-bit code is, the OS makes sure the selectors are set for long mode, the same process happens for 32-bit code except for that 1 bit.
Still have to setup the ldt, page tables etc.

64-bit is great for the extra registers and an assumed minimum level of SSEx as well as the address space.
The calling convention for win64 is ludicrous though...as I always complain  :bg

16 bit code is running in "compatible mode" under 32 bit, and 32 bit code is running in "compatible mode"
under 64 bit mode. This is what I mean. Hardware is already 64 bit. old applications run on "virtual machines"
losing some speed and efficiency. If you run 8 bit code in "virtual machines" it doesn't mean you are at the
top of market thoughts.  :P
Legacy code is important, this is the only reason it still runs on modern OSes and CPUs. But legacy tend to
diminish and change over time  :P

[redskull]

But legacy tend to diminish and change over time  :P

Man, do I wish I worked at your job.  I find things are just the opposite; people latch onto their legacy 16-bit apps, and outright refuse to change.  Accountants refuse to spend money to upgrade software "which still works fine".  Programmers create "new" applications by copy and pasting existing 16-bit code to get programs finished ASAP and managers off their backs.  People lost the source to that antique, undocumented software written by a consultant 20 years ago that's now irreplaceable because the guy who wrote it went through a bad divorce and killed himself.  We can't upgrade that payroll code that's written in Qbasic because Joe used to come in hungover and name every variable foo1, foo2, etc, and then got fired for banging the bosses daughter.  Those half-million lines of C-code can't be refactored because there isn't enough manpower to rewrite the old code *and* add new features, and the CEO will stomp the floor if he doesn't see any results.  And so on.

-r

[hutch--]

 :bg

red,

Sounds like you are having PHUN there. I have heard most of these over time but the one that always made me laugh was someone with a pile of old QBASIC cobbled together by a family member 20 years ago offers you the chance to evaluate then rewrite this pile of crap. Strange when they are disappointed by your lack of interest unless they want to specify the design requirements and PAY for it.

[jj2007]

I find things are just the opposite; people latch onto their legacy 16-bit apps, and outright refuse to change.
-r

Cute description :bg
You could add that these apps were written for slooooow hardware, and are therefore amazingly fast on a modern CPU...

[redskull]

I'm not sure which is worse; moron users or obsolete programmers.  It's always been amazing to me that non-technical users would rather have what's familiar, even though it's ridiculous, complex, and hard to use, rather than learning something new that's better.  One time I realized that one of the prompts the data entry drones had to fill in could be automatically retrieved from data elsewhere, so I went ahead removed that prompt, thinking I would get a nice 'attaboy' for making everyone's life easier.  Moments later, I had an office full of secretaries who wanted my head on a pike, because they were just so used to typing in that data that removing it threw their entire universe out of tilt. 

And then there's the relic programmers, who still think Windows and object oriented programming is some flash in the technology pan.  We have an embaressing large amount of "background network programs", which are really DOS programs that stay open and scan a hardcoded directory for a file every three seconds; if another program outputs that file to that directory using a mapped drive, the first one springs to life and does whatever is has to.  When i offered to rewrite these as actual windows services that use sockets for communication, I was told that "we don't go for those trendy hi tech fads here".  I wish i was kidding, but I work for a $10M a year company, and you can open any of our cash register drawers in the country by sending a carefully worded email to a particular address.  Really.

fuck my life  :'(

-r

[frktons]

I had my fair share of that crap some 30 years ago. Now thanks to God I'm almost
free from that nightmare. Now I just learn Assembly for FUN, and I can dream 64
bits, modern pc and OS, without having some nasty boss behind my shoulders taking
me back to the hard reality.  :P

[Rockoon]

But, a priory, I may to say, what 32bit app cannot be runned in 64bit mode with folders redirection only. Simple, because 64bit mode don't have (have, but use as another) some instructions, for example "push cs". Not very used instruction, but... :)

Thats irrelevant. That 32-bit OS uses the SAME mode to run 32-bit code that the 64-bit OS uses. All processors, aside from a few crappy ones, are 64-bit these days.

And, if 32bit app call to imported API, it called by address, which lies in 32bit range. So, in range of first 4GB must exist thunking code - to 64bits system.

You dont seem to understand. There is no thunking in 64-bit windows. 64-bit code cannot call 32-bit code, or vise-versa.

The WOW64 subsystem orchestrates the dynamic loading of alternative API DLL's. A 64-bit program loads only 64-bit DLL's. A 32-bit program loads only 32-bit DLL's. Those 32-bit DLL's do not (and can not) call the 64-bit DLL's.

The transition from 16-bit to 32-bit used thunking mechanisms to allow in-process mixing of 16-bit and 32-bit code. Win64 does not allow any in-process mixing.

For memory-management functions thunking code must done more things - alloc only in 32bit range, have table of allocations, and check it - what if all in 4GB space be allocated, etc.
So, if I don't mistaked, memory management under 64 for 32bit must be slower (not very).

No, it musn't be. You are confusing physical memory addresses with logical memory addresses. All modern userland programs only know of logical addresses. This entire paradigm is called Virtual Memory. Just because you have a buffer at offset 010000h does not mean that its *physically* at 010000h. It could be physically at 020000h, or 012340000h. Logically, it could be mapped at *both* 010000h for one process and 020000h for another.

Protected mode and Long mode allow 4K pages to be swapped around by simply manipulating an internal pointer, that further each process can have its own ordering, and so forth.

One of probable ways, how Microsoft done 32-to-64 thunking - with using RPC.
This mechanism is very used on all NT's. For example, when you call "WriteConsole[A/W]", progs run call to csrss.exe (Client-Server Run-time SubSystem).

This mechanism is used on both 32-bit and 64-bit OS's. Inter-process communications hasnt changed.

About AMDs' x64 extensions: it looks as very fastly developed and launched stuff, because many things looks as not very thinked-over.

How so? If it was just a rush to market, they wouldn't have obsoleted instructions in Long mode.

AMD64 won because it offered a compatibility mode with x86. Intels offering did not offer a compatibility mode, so it lost. Intel forget that compatibility is king, that it was compatibility that allowed it to topple the Motorola giant.