I'm working with Unicode strings (who doesn't these days) and I'm checking a search string for specific patterns, one of them is 2 *'s beside each other, the other is 2 !'s, then there's a single ?, to avoid any issues with search items.
Anyways, what I was *wanting* to do was add 2 to Edi to get the second one, and I ended up doing this:
Mov Al, [Edi]
Add Edi, 2
Mov Bl, [Edi]
Sub Edi, 2
Now I know the Motorola chips offer a "+" onto an effective address, but I tried with MASM and by putting Mov Bl, [Edi + 2] and it hates that idea. Is there another notation for this or does the Intel set not allow this. I am seeing this with LEA, but that really not what I want and I am just trying to squeeze as much speed out of this as I can (and avoid any memory access violations, why I didn't Mov a whole dword and also avoid any possibility of unaligned dword access).
GuruSR.
that should work
you can try mov bl, byte ptr [esi +2]
HSE, If you used ebx, or bx, instead of bl, "byte ptr" would be necessary. With bl it doesn't hurt but not necessary. And I think that's so with all of them: ML64, HJWasm, and asmc.
Quote from: HSE on October 23, 2016, 09:32:08 AM
you can try mov bl, byte ptr [esi +2]
Thanks, that assembles. Wasn't sure if the Intel instruction set allowed that or not. Just didn't like the add 2 and sub 2 just to read 1 byte. Not tested the changes to the code, but I can't see it not working, haven't included the new changes into the main code from that library, but chances are, it'll improve things.
Thanks,
GuruSR.
Hi rrr!
I don't have a PC now, but I think HJWASM work in that way.
Last weeks I was surprised by errors, later solved with typecast. Probably ML (I'm using for debugging and testing code compatibility), perhaps destination register was typecasted with ASSUME, not sure now.
Hi HSE!
I haven't used ML in a long time. I also can't check it right now but surely HJWasm knows that bl is a byte therefore byte ptr is assumed. Anyway you solved GuruSR's problem - that's what counts.
Well, the code changes do work, tested them out (after crashing it multiple times, my bad), but I cheated somewhat, I had a function that searched the unicode string for a unicode string pattern and returned the next 3 segments, one thing I didn't check for, empty pointers... I'll put that in later, to avoid those access violations.
It's part of my registry reading code, so stuff like searching for "Software\Classes\CLSID\!!" would take the two !! and return that "intent", and the next 2 sections (surrounded by \'s, if present). I then added in the functionality to pass items like this: "[HKU]\someuserid\Software\Classes\SomeClass" would be searched against "[HKU]\?\Software\Classes\**" and would match as the ? skips that section. Since adding those minor tests in for the search string into the existing pattern matching function, I turned it into 3 functions instead of one. Sadly, I logged the <BLEEP> out of it and I'm expecting a 1 to 4GB log file to sift through in the morning, as I think it's stuck in an infinite loop, well, not sure yet, as I can't read the log file while it's going, so if it's still stuck on that spot in 8 hours, I'll end it and start reading.
GuruSR.
Quote from: GuruSR on October 23, 2016, 02:35:01 PMthe unicode string ... It's part of my registry reading code
You might be better off saving as REGEDIT4, i.e. Utf-8, and using a fast instring as in this post (http://masm32.com/board/index.php?topic=4901.msg55846#msg55846).
Quote from: jj2007 on October 23, 2016, 02:54:21 PM
Quote from: GuruSR on October 23, 2016, 02:35:01 PMthe unicode string ... It's part of my registry reading code
You might be better off saving as REGEDIT4, i.e. Utf-8, and using a fast instring as in this post (http://masm32.com/board/index.php?topic=4901.msg55846#msg55846).
I wish, can't, but the code can't be that much faster, and because I'm utilizing it in a few ways, it'll be smaller. I'm happy with how it's working now, just wish I didn't log it so heavily.
GuruSR.
It occurs to me, there's something fishy going on here. If "mov bl, [edi+2]" requires "byte ptr", with whatever assembler you're using, then so does "mov bl, [edi]"
Reminds me of a wise dictum, insist on seeing a complete test routine to demonstrate someone's coding problem, before commenting on it
Quote from: rrr314159 on October 24, 2016, 03:20:30 AM
It occurs to me, there's something fishy going on here. If "mov bl, [edi+2]" requires "byte ptr", with whatever assembler you're using, then so does "mov bl, [edi]"
Reminds me of a wise dictum, insist on seeing a complete test routine to demonstrate someone's coding problem, before commenting on it
I had to look. MASM32 V8SP1 (according to the readme in the folder). It was odd that Easy Code didn't correct it for me, but I guess it didn't realize I needed the byte ptr in there with the Bl present. It's good though, working flawlessly and extremely quick, a lot quicker than what I was doing (C library with string matching, eesh, that was dog slow, wouldn't wish that on anyone).
GuruSR.
I've tested it: mov bl, [edi] works fine with ML 6.15, 8.0, 10.0 at least, plus JWasm, HJWasm and AsmC. None of them requires the byte ptr.
Quote from: jj2007 on October 24, 2016, 07:06:20 AM
I've tested it: mov bl, [edi] works fine with ML 6.15, 8.0, 10.0 at least, plus JWasm, HJWasm and AsmC. None of them requires the byte ptr.
Buuut, Mov Bl, [Edi +2] does not, hence my wondering why, since I'd seen other +'s being used in lea and figured it was the same, but it was using a dword ptr and after the coding I've been doing, being a bit burned out from it all, didn't think to try byte instead of dword.
GuruSR.
Quote from: GuruSR on October 24, 2016, 07:50:50 AMBuuut, Mov Bl, [Edi +2] does not
I've tested it: mov bl, [edi
+2] works fine with ML 6.15, 8.0, 10.0 at least, plus JWasm, HJWasm and AsmC. None of them requires the byte ptr.
Quote from: jj2007 on October 24, 2016, 08:50:47 AM
Quote from: GuruSR on October 24, 2016, 07:50:50 AMBuuut, Mov Bl, [Edi +2] does not
I've tested it: mov bl, [edi+2] works fine with ML 6.15, 8.0, 10.0 at least, plus JWasm, HJWasm and AsmC. None of them requires the byte ptr.
Alright, it didn't, but it is now. Only thing I can think of is the line had a ctrl code stuck in there somewhere somehow that was causing it to not compile, kept giving me a syntax error on that line, but after I re-wrote the entry from the Mov onward, using the Byte Ptr [Edi+2] it worked, so I'm thinking a ctrl code got in there somehow.
GuruSR.
Quote from: GuruSR on October 24, 2016, 12:20:01 PMOnly thing I can think of is the line had a ctrl code stuck in there somewhere somehow that was causing it to not compile, kept giving me a syntax error on that line, but after I re-wrote the entry from the Mov onward, using the Byte Ptr [Edi+2] it worked, so I'm thinking a ctrl code got in there somehow.
Yes, that can happen. One way it can occur, copying and pasting from a rich-text file or similar can introduce an invisible control code. If you'd known for certain the line was supposed to work you would have quickly realized it. But when you're not certain, something like that can easily put you on the wrong track
Quote from: rrr314159 on October 24, 2016, 12:30:25 PMcopying and pasting from a rich-text file or similar can introduce an invisible control code.
Yes, that can happen. For this scenario, the developers of assemblers have introduced "error messages" some time ago:
mov bl, [edi+1] ; OK
mov bl, [edi+1] ; [edi+hiddentext+1]: Error A2102: Symbol not defined : hiddentext
and [edi+2], 0 ; ML: error A2070:invalid instruction operands
and [edi+2], 0 ; HJWasm: Warning A4073: Size not specified, assuming: BYTE
Well, the error it was giving me was Syntax, which made no sense, which is why I was wondering what I didn't have right (syntax basically means the format of how it works and when you get an error, means you didn't format it correctly).
Mov Edi, DWord Ptr [SecOne] ; Ready output.
Mov Ecx, 00H ; Length of Section.
Cmp Edi, Ecx
Je NoOne
And another weirdness, it crashed, I debugged and I looked at the Edi and Ecx, both had 0's in them (Edi went to 1 after the Stosb, which caused the crash), but that Je never went to NoOne, passed it by. ZF should have been 1 in that situation and the two should have matched and Je should have bypassed the writing of section 1 because the storage for that section was invalid.
GuruSR.
Quote from: GuruSR on October 24, 2016, 11:18:34 PM
Mov Edi, DWord Ptr [SecOne] ; Ready output.
Mov Ecx, 00H ; Length of Section.
Cmp Edi, Ecx
Je NoOne
And another weirdness, it crashed, I debugged and I looked at the Edi and Ecx, both had 0's in them (Edi went to 1 after the Stosb, which caused the crash)
Nope, edi can't go to one using a stosb. Check it in the debugger:
xor edi, edi ; set to zero
int 3
stosbBtw:
Mov Edi, DWord Ptr [SecOne] ; Ready output.
Mov Edi, SecOne ; the assembler knows that edi is dword sized, and that SecOne is a memory location
Mov Ecx, 00H ; Length of Section.
xor ecx, ecx ; same effect, 2 bytes instead of 5
Similar:
mov SecOne, 0 ; 10 bytes
and SecOne, 0 ; 7 bytes, same effect
Quote from: jj2007 on October 24, 2016, 11:25:55 PM
Nope, edi can't go to one using a stosb. Check it in the debugger:
xor edi, edi ; set to zero
int 3
stosb
Btw:
Mov Edi, DWord Ptr [SecOne] ; Ready output.
Mov Edi, SecOne ; the assembler knows that edi is dword sized, and that SecOne is a memory location
Mov Ecx, 00H ; Length of Section.
xor ecx, ecx ; same effect, 2 bytes instead of 5
Similar:
mov SecOne, 0 ; 10 bytes
and SecOne, 0 ; 7 bytes, same effect
I tracked that 1 down to a null I was using, apparently it was... 1! So that include had a null set to 1, so I fixed it, solved the issue.
SecOne is the memory pointer to a buffer space, Ecx checks against the length of that (pre-supplied value of the length), just used to seeing the Mov dest, Dword Ptr [source] and figured since most were doing that, that it meant it was the best way to accomplish it.
I know about the xor trick, I use it elsewhere, but where I was doing that, I wanted to visually see what it was. I know the xor is faster and smaller, I actually haven't streamlined the code much, wasn't sure if there was anything out there to offer such. I remember doing it manually on my CRC library.
GuruSR.