Ignore MASM and it will go away

[hutch--]

You will have to forgive me if I don't take this "slash your wrists" approach as I have heard all this stuff before. We were told in 1995 and later that masm was finished yet a couple of years later it re-emerged as a patch for the old version that upgraded it to a 32 bit PE file. Microsoft have not sold MASM as a seperate product since masm 6.11 as a 16 bit package with limited 32 bit capabilities in 32 bit NT yet they released the series of patches up to 6.14 well after they stopped supporting MASM as a product.

Face it that new products for a new OS will be crap for some years as was the case with win95 and that was when there was still money in software development. We are in an era of decline of software production as the market demand from the consumer market has collapsed so the development money will be smaller and slower than it was back then. 32 bit Windows is a very good performer and with 10 years of software behind it, there is no mad rush to 64 bit unless you are a corporate client that needs very large addressing modes for databases and the like.

The PC market both rose and fell on the back of the domestic consumer demand and without it in an economic era when computer sales are down from the middle 90s, nothing will happen all that fast. If ML - 64 is a flop which is by no means certain, the market will ignore it but it also needs to be understood that 64 bit x86 Windows is still subject to major change so there is little reason at the moment to specify a dedicated version when the OS may change.

[Porkster]

Hutch you are way more professed than I am in this subject, but, even though the 64bit CPU's are being sold on "Extended Memory 64 Technology" there are more benefits than just range of virtual memory.   Wont arithmetic speed increase for non FPU calculations or programs that use large integers increase in speed?  Not sure if the trade off of pointer sizes and integer inefficiencies will be enough though.  (I have done little research into this so please forgive stupidity...  ehhe)

Also within a short period (1 year or more) most of the main market computers will be using WindowsXP64.  No one will like running 32bit applications/utilities with compatibility modes on or setting them up to run properly.  Most users will demand win64 rewrites, and that will create market competitiveness that developers will need to meet, in my opinion.

It's going to be a problem to recompile MASM source into full compatible win64 mode if we don't all start getting serious about work-around's, if Microsoft drops high level support in ML64.

Lets hope MS give us enough coding/status power to macro the features needed.

(EDIT)  Just found this site, talks about benefits of 64bit cpu's http://www.redbooks.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0475.html?Open

.

[hutch--]

This is the bit that has me stuffed, we have had win32 for something like 9 years and it has been an ever changing market so the prospect of win64 is in itself no big deal. What I fail to understand is the "panic stations" I am hearing when nothing is going to happen in a hurry. 64 bit has been with us for a long time but it is a narrow section of the IT market that can actually use it so it has not exactly taken over the world in a hurry.

Intel had 64 bit hardware back in the late 80s from memory but you must have a use for it. Noting tht the consumer market has blunted the pace of change that large vendors would like to have by just not buying new computers for some years, unless win64 offers some advantage it will only hit the corporate sector which is an effective closed market anyway.

Just remember the last 64 bit revolution with the Itanium fell flat on its arse ecause of cost and performance problems and most people were happy to continue to use their 32 bit win boxes as they did the job. Few have really demanding applications and even with the current office installed with every option, none of it is speed critical. A win98 box played games well so there is no great drawcard there either.

64 bit will come but its not badly needed at the moment where 640k was a genuine pain and the architecture of 16 bit Windows was no joy to work with or get things going with. Its hard to justify spending another fortune on software when the stuff you have works fine. Even thogh I have recentl;y put in all of office 2000, I still use my 1992 version of Word for help files as it does it better, faster and has more useful facilities to do that type of work.

When most people using a computer do a bit of word processing and some internet browsing, a cheap G4 MAC does the job and this is not a formula for the world at large rushing out to buy 64 bit Windows.

I just dont see a reason to panick about a new OS version when it will be some time before it actually matters.

[rea]

That will open intersting thing dont you think??? ;).

[GregL]

Something I am wondering about is if Windows x64 does not support x87 FPU instructions in a 64-bit application, what do you do for transcendental functions? For example you can't replace FSIN with anything in in SSE, SSE2 or SSE3. Do these functions have to be done entirely in software? If so, a program that uses a lot of these functions is going to be very slow.

[Randall Hyde]

"And switch to HLA64."
If it didn't have one fatal flaw...  the backwards order of the parameters,
it would be an excellent alternative, the especially the pascal flavor, like my favorite HLL.

All the high level languages I've used and various assemblers always have dest, source 
having to unlearn it for one language is too much.

If you don't like the operand ordering, it's easy enough to fix using macros. E.g.,

Code Select Expand


#id(mov)
#macro mov( dest, src );
  ~mov( src, dst );
#endmacro


and you can do that *today* with HLA v1.x.  HLA v2.0 (upon which HLA64 will eventually be based) will also support "templates", a compile-time language facility that lets you process arbitrary text in the assembly file, so if you wanted the syntax for your move instructions to be

Code Select Expand


mov dest, src

this will also be possible in HLA v2.0.

BUT..., HLA v2.0 is vaporware at this point. Then again, so is the big need for 64-bit computing. Hopefully, by the time 64-bit computing really takes off, HLA v3.0 (or similar) will be available :-)
Cheers,
Randy Hyde

[Porkster]

If WindowXP 64 runs 32bit applications in any lessor mode that is noticeable, then users will see the software in a condemned light.  The pros and cons of 64bit wont stop the masses from shifting from older technology.

Also businesses depreciate new purchased hardware so their need to maintain new computing vs tax ability/computing-demand.  Example a business will upgrade a computer even before it's worn out.  It's advantageous to stay ahead in technology then let your tax be fully paid.  So we should see a shift to 64bit desktop hardware in the mainstream, very quickly.   The transition to a 64bit OS maybe as fast as users moved from win95 to XP.

Thinking you can sit back and not learn the new setup is maybe unprofessional for those that are in the market of software development.

It will be interesting to see how sole assembler programmers go with developing software for win64/api's.   We are getting left behind at the moment, but hopefully we can catch up if ML64.exe is a good standard when released.

.

[GregL]

I also think Windows x64 is going to take off very quickly. Microsoft is going to release Windows x64 this spring, it's at Release Candidate 2 right now. The new Pentium 4s being released right now have EM64T and AMD64 PC's are widely available. I bet within 2 years it has a major percentage of the PC market.

[Faiseur]

Hi,

I understand like Greg. The market of the PC comes to maturity for transition 32-64 bit. That will be done of course gradually, but part of the users have a processor ready to pass to the 64 bit, that made much to contribute to the transition. 

[RedGhost]

voted 5 and left a comment

[drhowarddrfine]

Assembly programmers will never be left behind because it always boils down to assembly eventually and somebody needs an assembler to do it.

I remember years ago working for Qantel Systems and some of the field service guys making fun of the micro-coders coming from their dark back room.  They coded the "bit slice" processors.  There were only 3 or 4 of them.

[Randall Hyde]

I also think Windows x64 is going to take off very quickly. Microsoft is going to release Windows x64 this spring, it's at Release Candidate 2 right now. The new Pentium 4s being released right now have EM64T and AMD64 PC's are widely available. I bet within 2 years it has a major percentage of the PC market.

Win95 didn't cement the switchover to 32 bits that rapidly. And keep in mind that this was 10 years after 32-bit x86 processors first appeared (so nearly everyone had one).  Granted, there is less of a "culture shock" moving from 32-bits to 64-bits than there was moving from 16-bits to 32-bits, but I think that you vastly overestimate how rapidly people will switch to 64 bit processors and you're not considering at all the fact that most 32-bit machines in use today aren't going to be traded in for 64-bit machines anytime soon.
Cheers,
Randy Hyde

[GregL]

Randall,

  You may be right. It will be interesting to see how it plays out.
 

Regarding my post above:

  A well written SSE/SSE2 sine function beats the pants off of FSIN. Same for cosine, tangent etc. I was surprised.

[hutch--]

I must admit that after reading the specs for 64 bit Windows, I was seriously underwhelmed. Hybrid 32 / 64 bit code with segmented style addressing sounds terrible. the FASTCALL limitations are a genuine horror and it all sounds like a hardware limited botchup.

What I reallly wanted was a thoroughgoing 64 bit system with a terrabyte of memory and quad parallel 64 bit processors. Now if that is done right, it will be really impressive but it seems that will be a while yet.  :toothy

[Porkster]

I agree there is going to be alot more rules to programs in win64.  It's a bog down.

My guess points;

* Opcoding the EM64T opcodes wont be so difficult.
* Detecting the CPU modes with the system resisters wont be so difficult to manage with code.
* Win64's interface to the CPU will be clumsy
* Win64's OS requirements and happy states will be clumsy to work with low level code.

1. We may have to create multi methods to the different API modes if there are modes. Currently Hutch's database of API calls are all based on win32 API's.
2. We will have to consider paging and the IA-32e compatibility mode in the OS.
3. We maybe able to make a wrapper to interface the win64 API calls making it easy or uniform to process the calls.  This would distract from the proper learning of win64 API's though.

.