With thanks to Manhattan who showed everyone where the feedback to the dev team at Microsoft is, the current disposition from the development team seems to be to no longer support the INVOKE PROTO and OPTION PROLOGUE / EPILOGUE capacity in MASM. Without this capacity MASM would reduce down to just another mnemonic cruncher and that would be a net loss to so many people who have years of experience using MASM.
Over the years Microsoft have been very helpful to assembler programmers with the multiple ways of obtaining MASM to write code with so returning the compliment and giving then some useful feedback is a reasonable thing to do here. I have posted another suggestion to the development team at the following URL.
http://lab.msdn.microsoft.com/ProductFeedback/viewFeedback.aspx?feedbackId=FDBK21759
It is in fact a rare opportunity to be able to give feedback on a development tool that you regularly use so NOW is the time to tell the dev team at Microsoft. It is no big deal to register, costs you nothing and you don't get spammed for it. Your comments and votes will help to keep MASM as a premium tool for assembler programming. Ignore MASM and it will go away.
Voted. Rating: 5
Voted. Rating: 5
Voted. Rating: 5
ipadilla
Voted: 5
"Voted. Rating: 8"
Uh ? :U
Voted 5 on both issues, this and the one from "no hll syntax in MASM64" thread.
Same as above.
Voted. Rating: 5
I voted and left a comment.
voted also. yeah.
Dang, it wanted me to register to vote.
Then I thought "Does it really matter if INVOKE and some other macros are taken out of MASM?"
I think not. Someone will add a preprocessor if these items are removed.
I also dont think ignoring MASM will make it go away.
Still, if I didnt have to register I would have voted for your preference hutch.
Added a comment. Tried to vote, but an error occured. (?)
Thats OK James, I will send you a postcard while you are writing the parser. :green2
Quote from: striker on February 23, 2005, 01:20:03 AM
Dang, it wanted me to register to vote.
Then I thought "Does it really matter if INVOKE and some other macros are taken out of MASM?"
I think not. Someone will add a preprocessor if these items are removed.
I also dont think ignoring MASM will make it go away.
Still, if I didnt have to register I would have voted for your preference hutch.
You can always use HLA v1.x :-)
Cheers,
Randy Hyde
Voted.
Wouldn't have known about it if it wasn't posted in the Workshop.
Only later found the other thread in Soapbox, very rarely visit that forum.
I realized C/C++ was going to managed code compiling to IL Assembly code/binary
which then is translated by the runtime to native, but didn't know MASM was being
compromised/gutted.
How would device drivers and other performance critical code get written without a
fully functioning 64 bit MASM ?
Also how would Windows 64 bit x86 programmers write code ?
Thank for making the community of MASM programmers aware of it !
Voted 5
Quote from: dsouza123 on February 23, 2005, 10:47:20 PM
Voted.
I realized C/C++ was going to managed code compiling to IL Assembly code/binary
which then is translated by the runtime to native, but didn't know MASM was being
compromised/gutted.
Well, not supporting INVOKE is hardly *gutting* MASM. After all, you can still write macros that do much of what INVOKE does for you. True, it's a bit less convenient not to have INVOKE, but "gutted" is a bit strong here. :bg
Quote
How would device drivers and other performance critical code get written without a
fully functioning 64 bit MASM ?
Most device drivers are written completely in C, without a single line of assembly code. Those that do use assembly generally don't use the HLL control structures. And if you're writing performance-critical code, it's generally a good idea to skip the use of the HLL-like control structures, anyway. They tend to obscure code sequences that could be written in a faster manner. INVOKE, for example, obscures the fact that it wipes out the EAX register in certain cases.
Quote
Also how would Windows 64 bit x86 programmers write code ?
The lack of INVOKE/PROTO wouldn't stop them. A lot of 32-bit programmers might complain about the absence of these two facilities, but it's not the end of the world. People would adapt, even if it meant a few people actually switched back to C/C++.
Quote
Thank for making the community of MASM programmers aware of it !
Yes. Although eliminating INVOKE/PROTO wouldn't be the end of the world, the truth is that Microsoft needs to *extend* MASM's feature set, not shrink it. Sure, a lot of redundancy could be cleaned up (e.g., why not drop "db", "dw", "dd", etc., and just go with "byte", "word", "dword", etc., when moving to 64 bits?), but by and large they shouldn't *remove* functionality that doesn't have an immediate replacement.
Some things they ought to consider adding:
1. classes and objects.
2. Name mangling for VC++ compatibility.
3. Better compile-time language string handling facilities
4. The ability to nest macros in a context-free fashion (like HLA, NASM, and FASM support).
Cheers,
Randy Hyde
Gutted is quite appropriate.
At first it was going to be the control flow directives .WHILE etc and INVOKE, PROTO
That would remove most of the high level features of MASM,
you may not mind because you wrote HLA to replace MASM,
HLA only uses MASM among other assemblers as a back end,
if use of MASM is dropped as a back end there are fewer assemblers to deal with.
You should remove the equivalent items from HLA to see how usefull it is,
and to make the learning curve steeper.
Taking the high level features out of MASM would make it worse than the other assemblers.
It currently is a feature rich, stable programming tool.
Removing features goes down the slippery slope until there is nothing left and it is discontiued.
Removing INVOKE makes it far easier to write buggy code.
It is like removing type checking from high level languages.
The programmers that will miss the features in the language the most
are the new and intermediate ones, if it is made hard enough only a few
experts will be able to use it.
Device drivers used to be written in assembly.
Using INVOKE would be used early on and later could be replaced by more optimized code.
Code doesn't start optimized on the first writing, it gradually gets there.
"People would adapt, even if it meant a few people actually switched back to C/C++."
If the solution is to quit programming in Windows Assembly for 64 bit x86, then that isn't a solution.
If they decided to remove control flow and prototypes and type checking from C/C++ there would be a rebellion.
Taking away features that make it easier to write readable, less buggy code is foolish.
It is good to see most of the people in this thread value MASM with a strong feature set,
and not a cut down version that would make it far more difficult to write Windows Assembly.
QuoteINVOKE, for example, obscures the fact that it wipes out the EAX register in certain cases
In the way that is a macro, but the idea still nice, for example with goasm is that it hide the way that pass trought a substraction....
And I have considered such things for add, altought I really dont like to miss
HLL language with
structured programing I consider them a very diferent topic...
specially with the starters they even that have the while and functions hardly can write structured programming without know structure ;)....
The point in think that a HLL make you write structured programming is a way to force you to do it.... (hoping that you some day get the idea ;))
Like a extra thing Im thinking now that learn a HLL is a way of force your logic, because you normally learn the sintaxis and hope that you get the idea of the meaning of while/for/do/case/switch/foreach/..., but not the concepts that the HLL is bases or the tools that are used like the structured programming ie also included "packing" of instructions ala functions/files/functionality...
I have som friends that dosent get the idea of structure in the execution of instructions and the structure of the data... :), for example dosnt know for what they will use a "for" for traverse a array of structures.... they only use it if they have look ... and say is working, I hope some day things will be more clear :).
QuoteSome things they ought to consider adding:
1. classes and objects.
2. Name mangling for VC++ compatibility.
3. Better compile-time language string handling facilities
4. The ability to nest macros in a context-free fashion (like HLA, NASM, and FASM support).
and multipass so forward references wouldn't require an otherwise worthless proto.
Quote from: Randall Hyde on February 24, 2005, 03:58:40 PM
After all, you can still write macros that do much of what INVOKE does for you.
That's right:
_invoke MACRO funcname:REQ,p1,p2,p3,p4,p5,p6,p7,p8,p9,p10,p11,p12,p13,p14,p15,p16,p17,p18,p19,p20
local pos
FOR arg,<p20,p19,p18,p17,p16,p15,p14,p13,p12,p11,p10,p9,p8,p7,p6,p5,p4,p3,p2,p1>
IFNB <arg>
pos=@InStr(1,arg,<ADDR>) OR @InStr(1,arg,<addr>) OR @InStr(1,arg,<Addr>)
IF pos
IF (OPATTR(@SubStr(arg,%pos+5))) EQ 98
lea eax,@SubStr(<arg>,%pos+5)
push eax
ELSE
push OFFSET @SubStr(<arg>,%pos+5)
ENDIF
ELSE
push arg
ENDIF
ENDIF
ENDM
call funcname
ENDM
I think users here are misunderstanding the ramification of removing INVOKE.
I'm no expert as I have only briefly looked into the subject, but if I'm correct to say, it would be a nightmare trying to determine which mode win64 is in if the MASM compiler can't do that for you when building the final code. Especially if the code works or is compatible with the different bit-plane/addressing modes of win64.
The result of taking out INVOKE would lead to MASM being used for small inline style code rather than large assembly program creation. Users could try to remain retro but that would be the death of the community. Coders that wanted to create large programs would be required to implement management code to work with win64 modes, which could be messy.
Microsoft needs to change MASM so that it can phrase the attributes of the INVOKE to suit the mode win64 is would/currently be in. The issue is, will they want to when they are promoting a intermediate language using world. Do they have a need to cater for whole assembler type programming.
Just an opinion, and I maybe wrong.
.
Quote from: dsouza123 on February 24, 2005, 05:07:19 PM
Gutted is quite appropriate.
Because INVOKE and PROTO aren't supported? Come on now... Even if MS removed *all* of the HLL control structures, I'd still claim it's not "gutted". After all, it can still do everything most of the other x86 assemblers can do (TASM and HLA excepted).
Quote
At first it was going to be the control flow directives .WHILE etc and INVOKE, PROTO
My remarks were strictly geared towards the absense of the INVOKE/PROTO, after the
announcement that the HLL control structures would be kept.
Even so, the assembler would hardly be "gutted", even if they were all removed.
Though assembly, and especially MASM, is enjoying a bit of a renaissance right now, especially because of the HLL features in MASM (and TASM/HLA), the bottom line is that the *vast* majority of serious assembly users program in a HLL like C and call assembly routines for critical code. Such serious users rarely take advantage of the HLL-like control structures; they could stick with C if they wanted to use those and their presence in their MASM code masks the reason for using assembly (high-performance code).
Granted, removing these features would discourage some people from writing complete apps in assembly, but that's such a *tiny* piece of the entire programming marketplace, that I doubt MS would serious care. They *do*, however, need to continue supporting MASM. Their own drivers and other code uses some MASM code (and some new code will continue to be written in assembly). Remember, HLL control structures were added to MASM when it was a commercial product. This was done for the benefit of assembly programmers who purchased the product (who at the time, btw, almost universally rejected those statements). Today, MASM isn't a commercial product and it is supported mainly for legacy and internal purposes at Microsoft. I can easily understand why they'd not want to bother supporting the HLL control structures -- they don't use them and it's an expense they don't particularly care about (supporting those statements, that is).
Quote
That would remove most of the high level features of MASM,
you may not mind because you wrote HLA to replace MASM,
HLA only uses MASM among other assemblers as a back end,
if use of MASM is dropped as a back end there are fewer assemblers to deal with.
HLA issues aside, MASM 6 & 7 will continue to be available. They're not *removing* the HLL control structures from those languages. They're simply opting not to include them in the next version of MASM. Not a direction any of us would like to see the language go, but MS doesn't support MASM for our benefit.
Quote
You should remove the equivalent items from HLA to see how usefull it is,
and to make the learning curve steeper.
You see the difference, don't you?
HLA was designed for beginners (and advanced programmers who grow up with HLA). It's support is geared around that audience. MASM, OTOH, gets continued support because of the need to support legacy device drivers and new device drivers that require assembly language. Those programmers are not beginners. Steep learning curve isn't an issue. Indeed, one could argue that by *removing* features from the assembler that device driver authors don't use, MS is *reducing* the learning curve for the assembler.
Quote
Taking the high level features out of MASM would make it worse than the other assemblers.
It currently is a feature rich, stable programming tool.
Removing features goes down the slippery slope until there is nothing left and it is discontiued.
I hate to say "I told you so...." but this is exactly what *I've* been saying for years. Specially, although MS is committed to supporting MASM in order to preserve their legacy code and satisfy the needs of those few device driver authors who must use assembly, the fact that MASM is *not* a commercial product pretty much means that "support" for this product is going to wane over the years. That this kind of thing would eventually happen was pretty obvious to me in the late 1990s (I can't claim it was obvious when I first started writing HLA in 1996, MASM was still a commercial product back then, but when Microsoft stopped selling MASM I knew that I'd made the right choice to move forward with my own assembler).
Whether or not the HLL/INVOKE/PROTO battle is won or lost at this point is not all that relevant. The bottom line is that the MASM community has just gotten a *very* strong indication of the future support of MASM.
The good news, however, is that the MASM 6 and MASM 7 products work just fine. As long as MS continues to make them available, the fact that MASM 8 or 9 doesn't support the HLL control structures won't be an issue. As for 64-bit assembly not supporting this stuff, it's not something to worry about. If history is any indication, 64-bit computing won't take off for another 10 years anyway.
Quote
Removing INVOKE makes it far easier to write buggy code.
It is like removing type checking from high level languages.
Well, at least they didn't remove type checking from MASM :-)
Seriously, though, you're making an argument for using HLLs and skipping the use of assembly.
Quote
The programmers that will miss the features in the language the most
are the new and intermediate ones, if it is made hard enough only a few
experts will be able to use it.
Uh, don't forget that the new and intermediate ones will have the option of using HLA (yep, a 64-bit version is planned). If they want to insist on sticking with HLL control structures once they master assembly, they can continue to use HLA. They won't be lost to assembly language 'cause MASM doesn't support such features.
Quote
Device drivers used to be written in assembly.
But rarely anymore. And what assembly does appear in drivers is mostly short little functions that get called from C. You don't need INVOKE and PROTO (or any of the HLL stuff) for that kind of code.
Quote
Using INVOKE would be used early on and later could be replaced by more optimized code.
Code doesn't start optimized on the first writing, it gradually gets there.
Irrelevant. If invoke is so important, and people can't live without it, they can always use HLA64, when it becomes available. Or they can write 32-bit code and stick with MASM.
Quote
"People would adapt, even if it meant a few people actually switched back to C/C++."
If the solution is to quit programming in Windows Assembly for 64 bit x86, then that isn't a solution.
If they decided to remove control flow and prototypes and type checking from C/C++ there would be a rebellion.
Taking away features that make it easier to write readable, less buggy code is foolish.
Perhaps some people would rebell. And switch to HLA64. You won't find me complaining :-). The bottom line is that Microsoft doesn't owe the MASM32 community anything at this point. Most MASM32 users obtained MASM for free. And most of the MASM32 code that I've seen is *hardly* earth-shaking (mostly it's demo code) -- it's not going to sell OSes or make Microsoft any money. And given the size of the assembly community, if *every* MASM32 programmer doing serious work switched to Linux tomorrow, I don't think it would have any impact whatsoever on Microsoft.
OTOH, adding those features to MASM64 has some very real cost (development and support) that Microsoft will definitely have to pay for.
Quote
It is good to see most of the people in this thread value MASM with a strong feature set,
and not a cut down version that would make it far more difficult to write Windows Assembly.
I agree. And I wish this initiative the best of luck. A more powerful MASM would encourage more people to program in assembly, even when more powerful tools such as HLA are available. However, I still argue that you're beginning to see the end of support for MASM, something I predicted over five years ago. Voting for continued support *will* extend MASM's life a bit, but I hope that the wise people around here are seeing that this is probably the beginning of the end of support for MASM.
Cheers,
Randy 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.
I certainly agree with Randy that win 32 will be with us for a lot longer than many expect. 64 bit code affords advantage to a reasonably small target market, large databases and files larger than 4 gig which are possible in this context. Sopme specialised image programs will be able to take advantage of the > 4 gig addressing range. While 640k was an endless pain for application design, 4 gig is a long way off being too small with similar problems.
I knew a lot of guys who put there development time and support for IA-64 and it predictably turned out to be a lemon with too many technical problems and very poor performance in x86 emulation. It had some life in multiprocessor mainframes but x86-64 will replace it there as well. I know there is a free version of XP64 but I don'tknow if the OS design is stable yet in terms of its architecture.
As was the case with win 32, the tools were crap for 2 to 3 years after it was introduced and that was with popular support for win95 from the consumer market but it is doubtful that win64 will get the same blast that win95 did. Expect to see poor, crappy and limited tools for some years with win64. VB / .NET and VC .NET and MFC quality code leading the pack.
There is the hint around that the compiler guys at Microsoft would LIKE to go in the RISC design direction slopping registers around all over the place which would be unfortunate as x86-64 is a NICE architecture for good quality assembler programming with extra registers and the CISC instruction range choice. While CISC is harder work for compiler designers, its a blessing for assembler programming.
Now in relation to 64 bit MASM, lousy lead version have occurred in the past. The first 32 bit capable versions were "very ordinary" (6.11 variants) and it was not until the full 32 bit PE patchs came out that MASM was viable again. There was a version for winNT 3.5 (6.11c) that was a real crap heap that no-one bothered to use. Microsoft did the work about 2 years down the track and made the PE version and it has been a very successful tool ever since.
I doubt that the 64 bit version will be any different and it will be shaped by demand. When you have very capable 64 bit assemblers available already in NASM and YASM, unless Microsoft want to give away the bottom end of the market so that the GPL movement can successfully infiltrate the Windows platform at the low end, they will in fact maintain MASM both for their own internal use as well as ensuring their own customer base is not forced to use tools under the GPL licence.
I probably differ with Randy on his views of the future of HLA, I see HLA as a new monolith looming on the horizon which will create a market of its own and develop a user base that will support it but I don't see that it will ever displace MASM as they are different tools with different concepts behind them. If MASM was removed from the market it would mean a shift to C and other assemblers as few will give away this power on the basis of fashion.
I found this on MSDN about the Windows x64 Calling Convention, pretty interesting.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/kmarch/hh/kmarch/64bitAMD_6ec00b51-bf75-41bf-8635-caa8653c8bd9.xml.asp
Quote from: Greg on February 26, 2005, 05:22:17 AMI found this on MSDN about the Windows x64 Calling Convention, pretty interesting.
Yes it's the point I was making earlier but no one seemed to care about the post.. INVOKE would be a hassle to implement properly. Not to mention the modes can change quickly in the OS between the IA-32e modes.
It maybe best to make INVOKE only usable in full 64bit mode, on the default calling convention. Coders can use the old ML.exe to make 32bit API stuff.
(EDIT) Actually I post this as a http://lab.msdn.microsoft.com/ProductFeedback/ViewWorkaround.aspx?FeedbackID=FDBK21759#3
.
Thanks Greg, interesting link. 4 GP registers reserved for parameter passing with any other pushed onto the stack. The general design seems to be crippled by RISC theory and additional complexity to handle the RISC ideas but where it is not needed, 64 bit x86 look like it should be fun stuff.
The comments on invoke are much as before, if they can support making conventional function style calls in the compilers, they can do it with invoke as well. What looks interesting is if you choose to use the stack in manual code, you end up with 4 more registers to play with in the code design so in your own procedures, you have a lot more registers to play with in intensive code.
It will depend on how API functions are implemented but if it fits tis RISC model, it will be the 1st 4 arguments in the 4 specified registers without being order sensitive and the rest on the stack which will be much like normal.
Code something like,
mov rax, val1
mov rcx, val2
mov rdx, val3 etc ....
push nxt1
push nxt2
push nxt3
call proc_address
mov retval, rax
After reading the Product Feedback's on MSDN for ML64, it's clear Microsoft is putting the dagger into the assembly community. ML64 is destine to be a mere assistance to larger program coding in high level languages.
MASM is a community that isn't purchasing packages nor are they helping intermediate languages to dominate.
Microsoft doesn't need a full fledge assembly compiler with high level constructs, anymore.
Lets hope the power in macro'ing and mode detection is still available in the final ML64 or we will be doomed to win32 compatibility mode or basic hard coding of assembly api's and other instruction flow.
.
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.
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
.
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.
That will open intersting thing dont you think??? ;).
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.
Quote from: dsouza123 on February 26, 2005, 12:43:23 AM
"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.,
#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
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
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.
.
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.
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.
voted 5 and left a comment
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.
Quote from: Greg on February 27, 2005, 06:42:09 PM
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
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.
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
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.
.
... and complications: we can't do PUSH r32, only PUSH r16 or PUSH r64; we can't use heavily used instructions like PUSHA or POPA; we can't use some combinations of new operands, like MOV BH,[R8]; we can't recompile most of our x86-32 code for x86-64 platform without modfications; under Win x64 in long mode, we can't use MMX or FP registers, ...
Quote from: MazeGen on March 01, 2005, 08:51:41 PM
... and complications: we can't do ...
Apart from the general protection faults that will happen, maybe IDE makers can help and warn coders of these breaches when typing in win64 code?? an idea...
.