Possible problems with SSE usage.

[ecube]

Greg,
I disagree with your disagreement, msvcrt is fine in the C/C++ world, but we're part of the ASM world gentlemen, a better, more efficient world where mediocracy is left at the door. Sure if you just want sub par functions you can use msvcrt, but myself, i'd rather use a blazing fast hand written ASM equivalent. Why? well partly because I enjoy the speed, but also because it's green technology, faster speed means less clock cycles which means more energy conserved.

[Rockoon]

..and how much energy are you burning while reinventing the wheel?

[oex]

..and how much energy are you burning while reinventing the wheel?

What!!!!!! Who invented that????

[ecube]

..and how much energy are you burning while reinventing the wheel?

Far less than if I were doing it in a bloated C/C++ IDE... Fact of the matter is there are abillion C/C++ forums and sites, if you wanna be a fanboy that's great, but don't knock ASM in the process, especially in one of the few corners ASM still flourishes.

[dedndave]

the msvcrt does some under-the-hood stuff that is difficult to emulate or replace
partly because it has been around long enough to have the bugs worked out
partly because ms may have used proprietary knowledge in some of the code
most of the functions i have played with seem to compare well, performance wise, against anything i can write
all in all, it's fast and well-behaved - and.... it's already written !!!   :P

i suppose, now that most CPU's support SSE2, it could be improved upon for some time-intensive functions
but - i think most of that has been (or is being) hashed over in the forum

[GregL]

E^cube,

I love programming with MASM too, but that's no reason to exclude other languages. I like to program in C, (Power)BASIC and shudder, oh my God, C# and even PowerShell.  The idea that since you're an ASM programmer you must exclude all other programming languages just doesn't sit well with me at all. The CRT functions are far from mediocre, they are usually slower than ASM written functions, but that's because they do a lot of error checking etc. that the ASM functions don't do.  Think about it, these functions have been beaten to death and tested over the years.  They're are very reliable and very stable functions. It has been very infrequently that I have needed the speed of a hand tuned assembly procedure, but when I do, I can do it.  ASM and C just go together, most C compilers include an assembler.  You have every right to use only ASM and no CRT functions, knock yourself out, but don't push your limitations on everyone else.

[ecube]

E^cube,

I love programming with MASM too, but that's no reason to exclude other languages. I like to program in C, (Power)BASIC and shudder, oh my God, C# and even PowerShell.  The idea that since you're an ASM programmer you must exclude all other programming languages just doesn't sit well with me at all. The CRT functions are far from mediocre, they are usually slower than ASM written functions, but that's because they do a lot of error checking etc. Think about it, these functions have been beaten to death and tested over the years.  They're are very reliable and very stable functions. It has been very infrequently that I have needed the speed of a hand tuned assembly procedure, but when I do, I can do it.  ASM and C just go together, most C compilers include an assembler.  You have every right to use only ASM and no CRT functions, knock yourself out, but don't push your limitations on everyone else.

i'm not pushing "my limitations" on anyone, i'm simply voicing my opinion, as you are. And the fact is,you and I are a completely different breed, myself, i'm an ASM warrior to the core, unrelenting dedication and devoting to the language I love. You as stated are not, more of a neutral programmer. The problem is this is not a time of neutrality, this is a time of war, language war, Microsoft has already fired the first shot by horrifically crippling masm64, and by completely removing inline asm support in visual studio x64. In response the community has fired back with projects like jwasm, fasm and goasm. That all work great on x64. So you enjoy hopping around to different languages, thats your progative, but don't push your nonchalant attitude on those who just want to code in ASM, on an asm forum...

[Rockoon]

..and how much energy are you burning while reinventing the wheel?

Far less than if I were doing it in a bloated C/C++ IDE... Fact of the matter is there are abillion C/C++ forums and sites, if you wanna be a fanboy that's great, but don't knock ASM in the process, especially in one of the few corners ASM still flourishes.

sigh...

why so defensive all of a sudden?

...was it because you dont really write in asm to be "green?"

I mean, its a good "point" .. but its not why you write in ASM. Really. Its not. You know it. I know it.

[Rockoon]

i'm not pushing "my limitations" on anyone, i'm simply voicing my opinion, as you are. And the fact is,you and I are a completely different breed, myself, i'm an ASM warrior to the core, unrelenting dedication and devoting to the language I love. You as stated are not, more of a neutral programmer. The problem is this is not a time of neutrality, this is a time of war, language war, Microsoft has already fired the first shot by horrifically crippling masm64, and by completely removing inline asm support in visual studio x64. In response the community has fired back with projects like jwasm, fasm and goasm. That all work great on x64. So you enjoy hopping around to different languages, thats your progative, but don't push your nonchalant attitude on those who just want to code in ASM, on an asm forum...

Come on now, fasm, and goasm were not started for the reasons you are declaring. In fact, they were started before those reasons could even have existed.

[ecube]

..and how much energy are you burning while reinventing the wheel?

Far less than if I were doing it in a bloated C/C++ IDE... Fact of the matter is there are abillion C/C++ forums and sites, if you wanna be a fanboy that's great, but don't knock ASM in the process, especially in one of the few corners ASM still flourishes.

sigh...

why so defensive all of a sudden?

...was it because you dont really write in asm to be "green?"

I mean, its a good "point" .. but its not why you write in ASM. Really. Its not. You know it. I know it.

Actually in part it is, i'm a big fan of the green, money, green tea, various plants... and yes green tech. i'm defensive because people are on the offense.

Also Jeremy is a smart guy, he recognized the ASM community had a large void that he could fill with Goasm, and choose to do so. That may not be his primary reason, but he took the time to write all that documentation etc, and spent years of his life on it, all for the public, so clearly he cares.  Unlike most C/C++ GPL projects, where the authors are disrespectful and rude, looking only for self promotion and most of the time donations, Jeremy on the other hand has asked for nothing, and IMO deserves everything. RadASM and EasyASM are similar. These are prime examples of the power of ASM, the power of devoted developers and users who don't give up when faced with difficult engineering challenges. These are the kind of people I respect,and appreciate.  :thumbu

[hutch--]

Folks,

Can we avoid the "assembler wars" here, different people have their reasons for using different tools, I simply respect their choice and don't inflict this stuff on them.

[jj2007]

;-)

Just in case somebody is still interested in the original topic: I have made the Recall macro "SSE2 safe".

include \masm32\MasmBasic\MasmBasic.inc   ; Download
   Init[/size]
   Recall "\masm32\include\windows.inc", MyArray$(), -1, lc
   Print Str$("%i lines found in Windows.inc\n", lc)
   For_ n=0 To Min(lc-1, 15)
      mov ecx, n                   ; we need some proof that
      lea ecx, [2*ecx+27]        ; this is assembler ;-)
      Print Str$("\nLine %i\t", n+1), Left$(MyArray$(n), ecx)
   Next
   Exit
end start

Output:

Code Select Expand

22272 lines found in Windows.inc

Line 1  comment * -=-=-=-=-=-=-=-=-
Line 2
Line 3        WINDOWS.INC for 32 bit MA
Line 4
Line 5        This version is compatible wi
Line 6
Line 7        Project WINDOWS.INC at the Masm F
Line 8
Line 9        http://www.masm32.com/board/index.php
Line 10
Line 11       WINDOWS.INC is copyright software licence
Line 12       MASM32 project. It is available completely
Line 13       for any person to use for purposes including
Line 14       commercial software but the file must not be in
Line 15       commercial package and the file may not be redist
Line 16       without express permission from the MASM32 project.

> This version is compatible with ML.EXE Version 8.0

Hutch,
It's compatible with 6.14, 6.15, 9.0 and JWasm, too.

[hutch--]

JJ,

> It's compatible with 6.14, 6.15, 9.0 and JWasm, too.

Do you think you can expand on this. I use all versions of ML.EXE from 6.14 to 10.0 and don't have any problems with the current form of Windows.inc. Noting that I don't get paid for maintaining this file, perhaps you could share with me what the problem is.

[jj2007]

> Noting that I don't get paid for maintaining this file, perhaps you could share with me what the problem is.

Cool down young friend :bg

I just wanted to encourage you to mention that it is compatible not only with 8.0. It's kind of a compliment, Sir Hutch :U

[hutch--]

 :bg

After midnight readings,  :U