Can't seem to get the addressing right.

[GuruSR]

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:

Code Select Expand


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.

[rrr314159]

that should work

[HSE]

you can try mov bl, byte ptr [esi +2]

[rrr314159]

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.

[GuruSR]

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.

[HSE]

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. 

[rrr314159]

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.

[GuruSR]

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.

[jj2007]

the 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.

[GuruSR]

the 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.

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.

[rrr314159]

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

[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

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.

[jj2007]

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.

[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.

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.

[jj2007]

Buuut, 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.