Note the different encoding. There is apparently no reason to use the long encoding, but both ML and UAsm do it 8)
include \masm32\include\masm32rt.inc
.code
start:
or ebx, -1
.Repeat
print str$(ebx), " ebx", 13, 10
.if ebx<=sdword ptr 0 ; 81FB 00000000
print "le", 13, 10
.else
print "gt", 13, 10
.endif
.if sdword ptr ebx<=0 ; 83FB 00
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc ebx
.Until ebx>1
inkey
exit
end start
Good spot JJ :t
Nobody noticed that because it is logical to do the second version, I myself would do this:
.if (sdword ptr ebx <= 0)
I'll see if it can be done the same with otherway round
deleted
Here are some variation what is happening:
174: .if (ebx <= 0)
000000000103103d 83 FB 00 cmp ebx, 0x0
0000000001031040 77 01 jnbe 0x1031043
175: nop
0000000001031042 90 nop
176: .endif
177: .if ebx <= 0
0000000001031043 83 FB 00 cmp ebx, 0x0
0000000001031046 77 01 jnbe 0x1031049
178: nop
0000000001031048 90 nop
179: .endif
180: .if (sdword ptr ebx <= 0)
0000000001031049 83 FB 00 cmp ebx, 0x0
000000000103104c 7F 01 jnle 0x103104f
181: nop
000000000103104e 90 nop
182: .endif
183: .if ( ebx <= sdword ptr 0)
000000000103104f 81 FB 00 00 00 00 cmp ebx, 0x0
0000000001031055 7F 01 jnle 0x1031058
184: nop
0000000001031057 90 nop
185: .endif
186:
187: .if ebx <= sdword ptr 0
0000000001031058 81 FB 00 00 00 00 cmp ebx, 0x0
000000000103105e 7F 01 jnle 0x1031061
188: nop
0000000001031060 90 nop
189: .endif
Quote from: nidud on August 28, 2017, 08:39:06 AMThe hll definition of if (...) is always signed
"always" is a big word - there are many hll out there...
You are right JJ, you can see in above examples that it is not the case 8)
deleted
Quote from: nidud on August 28, 2017, 09:57:37 AMProgramming is rule-based
Absolutely :t But the C/C++ fraction rules only 12% (https://www.tiobe.com/tiobe-index/) of the world of programming. The other 88% are free to define their own rules. They are not even obliged to call their numbers "type" or their procedures "class" 8)
QuoteLong debate:
QuoteThere is an attempt to include HLL in MASM, but it is currently not fully implemented. The first problem with the current implementation is that it doesn't work, and the second problem is that it's not High Level Language.
http://masm32.com/board/index.php?topic=902.0
Very long debate! When I reached the end of that page, I thought "oh no, only page 1 of 17 :dazzled:"
deleted
Quote from: nidud on August 28, 2017, 10:41:55 PMAnother integrated part of programming is logic
...
The default type of a number will for this reason be signed
In C/C++ logic, yes. The other 88% of the programming world are absolutely free to define their own logic ;)
deleted
:biggrin:
Therez rools and there's rules but some languages let you make more of your own than someone else's rewelz. By going under conventional high level languages you have more room to make your own rules as you are not restricted by someone else's rules but you must also be able to make it work and be convenient enough to use on a regular basis.
The two ends address different problems, with a high level language that does not have a rule that lets you do what you require, the burden is getting around those rules whereas at a lower level you can make your own rules but have to deal with the complexity of consistency and functionality. Both approaches have their respective virtues and vices.
Quote from: jj2007 on August 27, 2017, 02:57:20 PM
Note the different encoding. There is apparently no reason to use the long encoding, but both ML and UAsm do it
The expressions are not equivalent most of the time. ".if sdword ptr ebx<=0" is translated here to CMP r/m32,imm8 (Compare imm8 with r/m32) the other is translated to CMP r/m32,imm32 (Compare imm32 with r/m32).
Replace "or ebx, -1" (why or here?) with "mov ebx, -2147483647" and you will see they are not.
On the other hand, if you compare with larger values (not byte sized) they will be encoded the same way. For example,
".if sdword ptr ebx<=257" is encoded like "ebx<=sdword ptr 257"
Another point is that the program crashes when assembled with MASM, (I mean MASM from the last 20 years or so, not some museum MASM).
Quote from: aw27 on August 29, 2017, 12:25:58 PMThe expressions are not equivalent most of the time. ".if sdword ptr ebx<=0" is translated here to CMP r/m32,imm8 (Compare imm8 with r/m32) the other is translated to CMP r/m32,imm32 (Compare imm32 with r/m32).
Thank you for confirming that different encodings are being used. The number "0" is obviously an imm8, so a clever assembler can choose the shorter imm8 encoding, since the "0" is known at assembly time. This is why I started the thread.
QuoteReplace "or ebx, -1" (why or here?) with "mov ebx, -2147483647" and you will see they are not.
It is highly unlikely that the assembler would change encoding when changing the entry value of ebx, but here is code to test. With all my assemblers, encodings and results are identical. Btw, "or ebx, -1" is the short version of "mov ebx, 0FFFFFFFFh".
include \masm32\include\masm32rt.inc
.code
start:
or ebx, -1 ; my suggestion
mov ebx, -2147483647 ; José's suggestion
push 2 ; 3 iterations
.Repeat
print str$(ebx), " ebx", 13, 10
; int 3
.if ebx<=sdword ptr 0 ; 81FB 00000000
print "le", 13, 10
.else
print "gt", 13, 10
.endif
; int 3
.if sdword ptr ebx<=0 ; 83FB 00
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc ebx
dec dword ptr [esp]
.Until Sign?
pop eax
inkey
exit
end startQuoteOn the other hand, if you compare with larger values (not byte sized) they will be encoded the same way. For example,
".if sdword ptr ebx<=257" is encoded like "ebx<=sdword ptr 257"
Correct. This is what the thread is all about.
QuoteAnother point is that the program crashes when assembled with MASM, (I mean MASM from the last 20 years or so, not some museum MASM).
Not on my assemblers (ML 6.14, 6.15, 8.0, 9.0, 10.0, UAsm & friends). Please post the executable that crashes, and indicate which assembler and OS you were using.
Quote from: jj2007 on August 29, 2017, 05:44:36 PM
It is highly unlikely that the assembler would change encoding when changing the entry value of ebx
It is true, I just thought it would be enough for you to take conclusions.
Look at this case then:
include \masm32\include\masm32rt.inc
.code
start:
mov ebx, -2147483647
.Repeat
print str$(ebx), " ebx", 13, 10
.if ebx<=sdword ptr -1
print "le", 13, 10
.else
print "gt", 13, 10
.endif
.if sdword ptr ebx<=-1
print "le", 13, 10
.else
print "gt", 13, 10
.endif
inc ebx
.Until ebx>1
inkey
exit
end start
Quote
Not on my assemblers (ML 6.14, 6.15, 8.0, 9.0, 10.0, UAsm & friends). Please post the executable that crashes, and indicate which assembler and OS you were using.
Good rules dictate that developers must always use the latest versions of their tools. That's what I do.
Check with release 14 of MASM then.
Quote from: aw27 on August 29, 2017, 06:09:04 PM
Look at this case then:
I looked, and excuse my ignorance: where is the problem?
-2147483647 ebx
le
le
-2147483648 ebx
le
le
2147483647 ebx
gt
gtQuoteGood rules dictate that developers must always use the latest versions of their tools. That's what I do.
Check with release 14 of MASM then.
Whether your rules are good or not, I don't care - they are not
my rules (recent versions of MASM are very buggy, but that is no secret, right?).
I asked you to post the exe, and you didn't do that, for good reasons, I suppose 8)
Quote from: jj2007 on August 29, 2017, 06:30:26 PM
I looked, and excuse my ignorance: where is the problem?
You are correct. No problem. :t
Quote
recent versions of MASM are very buggy, but that is no secret, right?
I am not sure they are more buggy. They simply tightened their tolerance for bad practices. :lol:
Quote
I asked you to post the exe, and you didn't do that, for good reasons, I suppose 8)
You can assemble with MASM from your Visual Studio Community 2017 or 2015 editions and see for yourself.
Quote from: aw27 on August 29, 2017, 06:53:56 PMYou can assemble with MASM from your Visual Studio Community 2017 or 2015 editions and see for yourself.
Thank you so much for your valuable contributions to this thread, José. Unfortunately, right now I am busy with important things, so I won't have time to investigate the secrets of the slowest software I've ever seen. Btw did you ever fix the little bug in your almost correct (http://masm32.com/board/index.php?topic=6417.msg68774#msg68774) conversion routine (
"diff" is the difference between the Real4 and the converted Real8, and it should be zero, of course)?
Quote from: jj2007 on August 29, 2017, 07:25:34 PM
Unfortunately, right now I am busy with important things, so I won't have time to investigate the secrets of the slowest software I've ever seen.
Something is wrong with your hardware :badgrin:
It loads in less than 2 seconds in my i5 notebook:
(http://www.atelierweb.com\a\vs2017gif.gif)
Quote
Btw did you ever fix the little bug
What I remember from that thread is that I fixed your bug and you rushed to make something a little different in order to not recognize that. JJ is JJ :lol:
Quote from: aw27 on August 29, 2017, 07:39:39 PMQuote
Btw did you ever fix the little bug
What I remember from that thread is that I fixed your bug and you rushed to make something a little different in order to not recognize that. JJ is JJ :lol:
Your irrelevant remarks ("This looks wrong") and your (still) buggy code could
not help me to identify the bug that I fixed minutes later. Anyway, that thread is public, so everybody can see the "conversation" (http://masm32.com/board/index.php?topic=6417.0) :P
@JJ
So, you said "Thank you, José - you are right, the mov eax, ecx was redundant. Here is the final version:" and 1 month later it is not anymore? You are one of a kind. :greenclp:
Jose,
Make me wiser, what does my download page have to do with starting VS ?
Quote from: hutch-- on August 29, 2017, 08:31:41 PM
Jose,
Make me wiser, what does my download page have to do with starting VS ?
Hutch,
We hear JJ complain all the time that VS tools are slow to load. They are indeed very fast. The slowest one I know is VS2015 which will take a few more seconds. Probably, JJ should consider it is time to get a new computer. ;)
Quote from: aw27 on August 29, 2017, 08:05:03 PM
@JJ
So, you said "Thank you, José - you are right, the mov eax, ecx was redundant. Here is the final version:" and 1 month later it is not anymore? You are one of a kind. :greenclp:
Even one month later, your remark about the
mov eax, ecx is still valid, and I thanked you for spotting that. It was indeed redundant, so I removed it - 2 bytes less, thank you so much again. But it had nothing to do with the problem, and it won't change the fact that your buggy code is still waiting to be fixed while my version is working perfectly. Maybe you should consider using less buggy tools (http://masm32.com/board/index.php?topic=6508.0)?
Re slow computers: My Core i5 is faster than the average computer, and definitely fast enough when using my own software. There is a reason why I am hanging around here, in an assembler forum: I like fast
software. Not bloated tools like VS Community; a Google search for
visual studio community slow yields "About 9,330,000 results" :bgrin:
I will admit, though, that my VS Community would load in "less than 2 seconds" if I used it so often that the whole crap was already in the cache. But I am not a masochist :P
Quote from: jj2007 on August 29, 2017, 08:55:21 PM
But it had nothing to do with the problem, and it won't change the fact that your buggy code is still waiting to be fixed while my version is working perfectly.[/url]?
I don't think it is buggy. I remember there was indeed a bug the first time I posted but I fixed it sometime later. I am too lazy to go again through waters passed under the bridge.
Quote
Re slow computers: My Core i5 is faster than the average computer,
:badgrin:
Quote
a Google search for visual studio community slow yields "About 9,330,000 results" :bgrin:
I tried "who is JJ" in Google and got 26 400 000 results. :badgrin:
Quote
I will admit, though, that my VS Community would load in "less than 2 seconds" if I used it so often that the whole crap was already in the cache. But I am not a masochist :P
Actually not, I only use the notebook when go out for the weekend and have probably loaded VS2017 3 or 4 times.
Quote from: aw27 on August 29, 2017, 09:34:03 PMI don't think it is buggy. I remember there was indeed a bug the first time I posted but I fixed it sometime later.
The code you posted here (http://masm32.com/board/index.php?topic=6417.msg68773#msg68773) has indeed a fat bug, and you never fixed it. Your original code is contained in the archive attached to Reply #5
*) and produces wrong results:
-- R4ToR8 jj --
R4: -123456.789 R8: -123456.789 diff: 0.0 ; zero is correct
R4: -111111.789 R8: -111111.789 diff: 0.0
...
R4: 37028.2109 R8: 37028.2109 diff: 0.0
R4: 49373.2109 R8: 49373.2109 diff: 0.0
-- R4ToR8 aw27 --
R4: -123456.789 R8: -123456.781 diff: 0.0078 ; non-zero is WRONG
R4: -111111.789 R8: -111111.781 diff: 0.0078
R4: -98766.7891 R8: -98766.7812 diff: 0.0078
R4: -86421.7891 R8: -86421.7812 diff: 0.0078
R4: -74076.7891 R8: -74076.7812 diff: 0.0078
R4: -61731.7891 R8: -61731.7812 diff: 0.0078
R4: -49386.7891 R8: -49386.7812 diff: 0.0078
R4: -37041.7891 R8: -37041.7812 diff: 0.0078
R4: -24696.7891 R8: -24696.7812 diff: 0.0078
R4: -12351.7891 R8: -12351.7891 diff: 0.0
R4: -6.78906250 R8: -6.78906250 diff: 0.0
R4: 12338.2109 R8: 12338.2109 diff: 0.0
R4: 24683.2109 R8: 24683.2031 diff: -0.0078
R4: 37028.2109 R8: 37028.1875 diff: -0.023
R4: 49373.2109 R8: 49373.1875 diff: -0.023*) Since you will surely complain that ConvertFloats.asc "does not open": Use Wordpad to see the content.
@JJ
You are using a case I barely remember, and that did not even came on the way in this thread, to compensate for dozens of situations I made you swallow your anger.
Pure revenge :badgrin: .
Looking forward for more rabbits to come out of your hat.
Every time I have ever installed VS over the last few years, loading the IDE is a genuine pain and the Haswell I am using is no slouch. The last i7 was a reasonably fast machine and it was slow on it as well. After I install VS, I grab all of the files I want then delete it so it does not try and hog file extensions.
Quote from: hutch-- on August 29, 2017, 11:23:28 PM
Every time I have ever installed VS over the last few years, loading the IDE is a genuine pain and the Haswell I am using is no slouch. The last i7 was a reasonably fast machine and it was slow on it as well. After I install VS, I grab all of the files I want then delete it so it does not try and hog file extensions.
I have a 500 GB SSD which serves as drive C, where is installed VS. This explains most of the speed.
Quote from: aw27 on August 29, 2017, 11:10:20 PMdozens of situations I made you swallow your anger.
My dear friend, why should I be angry about you? It's fun to argue with you :badgrin:
Quote from: jj2007 on August 29, 2017, 11:53:35 PM
It's fun to argue with you :badgrin:
I think the same, it is fun to argue with you! :lol:
:biggrin:
Just remember that if you scratch each other's eyes out you code quality will drop dramatically. :P
Quote from: hutch-- on August 30, 2017, 12:46:58 AM
:biggrin:
Just remember that if you scratch each other's eyes out you code quality will drop dramatically. :P
In the end JJ gave me the opportunity to fix the small typo (he calls it a fat bug) in the code I produced one month ago to fix the fat bugs in his own code. :lol:
:biggrin:
Well, you could get yourself a braille keyboard. :P
Quote from: aw27 on August 30, 2017, 02:02:21 AMIn the end JJ gave me the opportunity to fix the small typo
Thread is already updated. Your code is even a tick faster now, and one byte shorter than mine :t
Quote from: jj2007 on August 30, 2017, 03:34:37 AM
Quote from: aw27 on August 30, 2017, 02:02:21 AMIn the end JJ gave me the opportunity to fix the small typo
Thread is already updated. Your code is even a tick faster now, and one byte shorter than mine :t
:t
Phuk! you really inspire me guys. :biggrin:
Another thumb up for this great forum :icon14:
:greenclp:
:lol: