News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

Dynamic association

Started by gelatine1, November 11, 2014, 02:33:25 AM

Previous topic - Next topic

gelatine1


; The following is to skip leading spaces without generating an error

space_check:
   inc  esi             ;point to next character
   mov  al,[esi]        ;get character
   cmp  al," "          ;is it a space
   jz   space_check     ;check for another space

; Check 1st non-space character for + or - sign

   .if  al == "-"       ;is there a "-" sign
      mov  byte ptr [edi],80h ;changes the sign byte for the negative code
      inc  esi          ;point to next character

   .elseif al == "+"    ;is there a "+" sign
      inc  esi          ;point to next character,
                        ; the sign byte is already coded positive
   .endif

integer_count:
   .if  al == 0         ;is it the end of the source string
      jmp count_end
   .elseif al == "."    ;is it a "period" decimal delimiter
      jmp decimal_count
   .elseif al == ","    ;is it a "coma" decimal delimiter
                        ; (also used in numerous countries)
      jmp decimal_count
   .elseif al < "0"     ;is it an invalid character below the ASCII 0
      jmp input_error
   .elseif al > "9"     ;is it an invalid character above the ASCII 9
      jmp input_error
   .elseif ch == 18     ;is digit count already at the maximum allowed
      jmp input_error
   .endif

   inc  ch              ;increment the count of integers digits
   inc  esi             ;point to next character
   mov  al,[esi]        ;get character
   jmp  integer_count   ;continue counting integer digits



I was reading this code on rays tutorial for FPU (http://www.ray.masmcode.com/tutorial/fpuchap6.htm) but I noticed this weird (maybe wrong ?) code. The value of al is not updated by just increasing esi in that part for space checking right ? Or is there some kind of dynamic association that keeps al equal to [esi] at all times ? Or am I just interpreting this completely wrong ?

Thanks in advance

Gunther

Hi gelatine1,

Quote from: gelatine1 on November 11, 2014, 02:33:25 AM
I was reading this code on rays tutorial for FPU (http://www.ray.masmcode.com/tutorial/fpuchap6.htm) but I noticed this weird (maybe wrong ?) code. The value of al is not updated by just increasing esi in that part for space checking right ? Or is there some kind of dynamic association that keeps al equal to [esi] at all times ? Or am I just interpreting this completely wrong ?

ESI is a pointer to an ASCII string and the instruction:

         mov  al,[esi]        ;get character

updates the content of AL.

Gunther
You have to know the facts before you can distort them.

gelatine1

Hey gunther,

Actually my main question is if there is something wrong with that code I posted or not ? I believe the content of al is not always updated at the right moments.

Jannes

qWord

Quote from: gelatine1 on November 11, 2014, 11:52:39 PMis something wrong with that code
yes.
Integers beginning with '+' or '-' are rejected, because AL is not updated after increasing ESI.
MREAL macros - when you need floating point arithmetic while assembling!

gelatine1

Well then I guess Ray (from that website) should be contacted. Anyone knows if he is active on these forums ?

dedndave

Raymond checks in once in a while   :t

Tedd

The code is correct.
The leading sign is skipped if present, however the byte at edi is made negative if the sign was negative; the rest of the result is stored at edi, which results in the stored BCD value being correctly negative as required. al doesn't need to be updated in this case.
Potato2

nidud

#7
deleted

Gunther

Quote from: Tedd on November 12, 2014, 06:37:46 AM
The code is correct.
The leading sign is skipped if present, however the byte at edi is made negative if the sign was negative; the rest of the result is stored at edi, which results in the stored BCD value being correctly negative as required. al doesn't need to be updated in this case.

that was my point of view, too.  :t But qWord has another opinion.

Gunther
You have to know the facts before you can distort them.

qWord

The function jumps to input_error if a number starts with '+' or '-', because the succeeding range check ['0', '9'] does fail.
MREAL macros - when you need floating point arithmetic while assembling!