I decided to take the leap into fasm and I like it so far. I am converting one of my small apps from masm to fasm and am getting an error I can't figure out:



or eax, eax
jz zero ;<----------- here

flat assembler version 1.46
oelc.asm [749]:
jz zero
error: invalid value.

Make error(s) occured.


even if I change to 'jnz notzero' I get the same error.

Confused
Posted on 2003-05-14 13:04:13 by Gunner
How did you define the zero label?
Posted on 2003-05-14 13:08:50 by Tomasz Grysztar
defined the label as:
zero:
Posted on 2003-05-14 13:26:52 by Gunner
OK, so there's other reason. Could you give the whole source that causes an error?
Posted on 2003-05-14 13:31:38 by Tomasz Grysztar
Trying to convet dwtoa


.
.
.
movzx edx, al
push ebx
push edx
call dwtoa
.
.
.
proc dwtoa, dwValue, lpBuffer
enter
push ebx
push esi
push edi

mov eax,
mov edi,
test eax, eax
jz zero

signed:
jns pos
mov byte ,'-'
neg eax
inc edi

pos:
mov ecx,429496730
mov esi, edi
jmp dw2asc

zero:
mov word ,30h

@@:
test eax, eax
je Next
;.while (eax > 0)
mov ebx,eax
mul ecx
mov eax,edx
lea edx,
add edx,edx
sub ebx,edx
add bl,'0'
mov ,bl
inc edi
;.endw
jmp @B

Next:
mov byte , 0 ; terminate the string

; We now have all the digits, but in reverse order.

@@:
cmp esi, edi
jg Next2
;.while (esi < edi)
dec edi
mov al,
mov ah,
mov , al
mov , ah
inc esi
; .endw
jmp @B

dw2asc:

pop edi
pop esi
pop ebx
return
Posted on 2003-05-14 13:39:37 by Gunner
After adding the missing Next2 label this code works OK for me - there must be something other in your source that causes the error to occur. Please give the whole file that causes the problem.
Posted on 2003-05-14 13:44:18 by Tomasz Grysztar
Everyting compiled fine until I added to the source:


proc ConvertToDec, lpStringIn, lpStringOut
enter
push esi
push edi
push ebx
push edx

mov esi, [lpStringIn]
mov edi, [lpStringOut]

@@:
mov al, byte [esi]
inc esi
cmp al, 0
je @F
mov word [edi], '#&'
add edi, 2

; push eax
; push 00H
; push 4
; lea ebx, [Temp]
; push ebx
; call memfill
; pop eax

movzx edx, al
push eax
push ebx
push edx
call dwtoa
pop eax


push eax
push ebx
push edi
call szCatStr
pop eax

push eax
push ebx
call StrLen
add edi, eax
pop eax
mov byte [edi], ';'
inc edi
jmp @B

@@:
mov byte [edi], 00H

pop edx
pop ebx
pop edi
pop esi
return

proc dwtoa, dwValue, lpBuffer
enter
push ebx
push esi
push edi

mov eax, [dwValue]
mov edi, [lpBuffer]
test eax, eax
jz zero

signed:
jns pos
mov byte [edi],'-'
neg eax
inc edi

pos:
mov ecx,429496730
mov esi, edi
jmp dw2asc

zero:
mov word [edi],30h

@@:
test eax, eax
je Next
;.while (eax > 0)
mov ebx,eax
mul ecx
mov eax,edx
lea edx,[edx*4+edx]
add edx,edx
sub ebx,edx
add bl,'0'
mov [edi],bl
inc edi
;.endw
jmp @B

Next:
mov byte [edi], 0 ; terminate the string

; We now have all the digits, but in reverse order.

@@:
cmp esi, edi
jg dw2asc
;.while (esi < edi)
dec edi
mov al, [esi]
mov ah, [edi]
mov [edi], al
mov [esi], ah
inc esi
; .endw
jmp @B

dw2asc:

pop edi
pop esi
pop ebx
return

proc szCatStr, lpszSource, lpszAdd
enter
push esi
push edi
push ebx

push [lpszSource]
call StrLen
mov edx, [lpszSource]
mov ecx, [lpszAdd]
add edx, eax

@@:
mov al, [ecx]
mov [edx], al
inc ecx
inc edx
test al, al ; test for zero
jne @B

pop ebx
pop edi
pop esi
return


proc StrLen, item
enter
push esi
push edi
push ebx

; -------------------------------------------------------------
; This procedure has been adapted from an algorithm written by
; Agner Fog. It has the unusual characteristic of reading up to
; three bytes past the end of the buffer as it uses DWORD size
; reads. It is measurably faster than a classic byte scanner on
; large linear reads and has its place where linear read speeds
; are important.
; -------------------------------------------------------------

mov eax,[item] ; get pointer to string
lea edx,[eax+3] ; pointer+3 used in the end
@@:
mov ebx,[eax] ; read first 4 bytes
add eax,4 ; increment pointer
lea ecx,[ebx-01010101h] ; subtract 1 from each byte
not ebx ; invert all bytes
and ecx,ebx ; and these two
and ecx,80808080h
jz @B ; no zero bytes, continue loop
test ecx,00008080h ; test first two bytes
jnz @F
shr ecx,16 ; not in the first 2 bytes
add eax,2
@@:
shl cl,1 ; use carry flag to avoid branch
sbb eax,edx ; compute length

pop ebx
pop edi
pop esi
return
Posted on 2003-05-14 13:59:53 by Gunner
The code compiled without errors for me (using fasm(w) 1.46, w/ the bug fix for "check_for_reserved_word"-bug).
I attach the source I compiled using fasmw 1.46 (assembler core unmodified with exception for the bug fix).

It also compuiled when attding these three lines at the top:
format PE
entry start
start:
and this before the procs:
section '.text' code readable executable
Posted on 2003-05-14 14:13:50 by scientica
Yes, here it also compiles fine. I don't know why do you have such problem. Anyway, you still didn't post the whole .asm file, maybe there's something in other part of source that causes it?
Posted on 2003-05-14 14:59:51 by Tomasz Grysztar
Just came to think about "Error: Invalid Value", since I just got one, I think the error is due to the fact that I'm playing around with sections, but I don't know.

I have one section in Send300.inc (section '.code300' code readable executable) where this error occurs when compiling (I "expanded" the code and the error actually occurs at call StrLen):
flat assembler  version 1.46.9.2

%_root%\Send300.inc [10] stdcall [3]:
stdcall StrLen, [Buf]
error: invalid value.

I have the StrLen procedure in a second section (section '.text' code readable executable), in an other file.
Posted on 2003-05-20 09:15:25 by scientica
scientica: if it appears to be bug, can you give me the whole source that causes the trouble so I'd be able to reproduce that behavior?
Posted on 2003-05-20 09:19:46 by Tomasz Grysztar
Ok, here comes some of the hole source code (I stripped a few files, resoures and some lines of code that doesn't affect the error). If you need more of source code, tell me and I'll zip it.
Posted on 2003-05-20 09:55:33 by scientica
You forgot to put "enter" macro after the proc definition and it caused everything after to be assembled inside the virtual block.
Maybe we should put some check into "return" macro to detect procs with missing "enter"...
Posted on 2003-05-20 11:28:40 by Tomasz Grysztar
Thanks, yes it would be an good Idea to add that, so that I can avoid these, embarrasing, misstakes. :)

It compiles fine to the next error. :alright: ;) (I've ported the project from masm to fasm, so ther'll be many more bugs to go before I can write somethiong new in it).
Posted on 2003-05-21 09:05:43 by scientica
jmp @F
This code gives the following error:
[color=grey]                        jmp     .f

@@:
mov ebx,[FSize]
sub [FSize],eax
mov ecx,ebx
dec ecx
invoke wsprintfA,Buf1,Msg206,[pType],[FOffset],ecx,ebx,[FSize]
.f:[/color]

[color=grey]flat assembler  version 1.46.9.2

Commands.inc [167]:
jmp .f
error: invalid value.[/color]
I tried to comment it out, and then the same error occured later in the code (outside the included file, in the "master" file), a forward jump to a local label resutls in a "invalid value"-error. The code is located in an included file, included in a procedure with some forward jumps to local labels before the includeed file, no errors there. All the code is with in a singe code segment, the procedure begins (after the proc function...-line ) with enter and ends with return.
@@:

After a lightning just struck me and forced me to try adding an 'o' after the .f, thus making it .fo and .fo:, and it compiled on to the next error of the same type, it now apears to me as if foward jumps to local labels with a single letter as name results in an "invalid value"-error.

While looking throught my sources I found a "jmp" to a label with jsut one letter, no error at this point, the next error is at an, conditional jump, so to me it appears as conditional forward jumps generates this error.
Posted on 2003-05-21 10:43:38 by scientica
No, it's just because FASM sees .f as a floating point value, sorry. I'm not even sure if I should fix that (1.f and .1f should be recognized as a floating point values, for sure; or maybe I should demand at least one decimal digit after the dot?).
Posted on 2003-05-21 11:17:35 by Tomasz Grysztar
The second error-label was .E: , is .E like .f?

Here comes my feedback: (I got the feeling you wanted to hear my oppinion, and if you didn't you don't need to read it ;))
.1f - ok, there it should not be mandontory with a leading zero, even thought I thing one should put a 0 first, imagine writing "1/10 = .1" in a mathematics book in school, the teacher wouldn't like it, but (s)he wouldn't kill the one who does it, just express how wring (s)he thinks it is, so why not let fasm generate a waring "warning: missing leading zero", but assemble it. (one my calculator for instance one can write .decimals, skipping the leading zero, the manual ever recomends it, for saving sapce when writing BASIC scripts)

1.f - well this, I think it should generate an error, since if you put a decmal point then you show your intension to add further precision, when I see something like . I think, oh no, somebody forgot to write some decimals. Either it is 1f or 1.0f (or even more zeros, to indicate "valid digits"/precision of the number).



Just a quick qestion, is a @@-label treates as a normal label, making all local variables following the @@-label be local to the @@ label? (what I mean is, well, se below).
label1:

.hi ;label1.hi
@@:
.hello ; is it label.hello or @@.hello ?
Posted on 2003-05-21 12:02:06 by scientica

1.f - well this, I think it should generate an error, since if you put a decmal point then you show your intension to add further precision, when I see something like . I think, oh no, somebody forgot to write some decimals. Either it is 1f or 1.0f (or even more zeros, to indicate "valid digits"/precision of the number).

Yeah, 1.46.9.3 thinks the same. ;)



Just a quick qestion, is a @@-label treates as a normal label, making all local variables following the @@-label be local to the @@ label?

No. The anonymous labels are completely transparent for the rest of code.
Posted on 2003-05-21 12:47:35 by Tomasz Grysztar

Yeah, 1.46.9.3 thinks the same. ;)

:)


No. The anonymous labels are completely transparent for the rest of code.

Good, then the error is somewhere else among the numberous labels :)
the truth is out there, (so are the bugs) - my sources feels like an x-file... ;)
Posted on 2003-05-21 13:00:11 by scientica
Both .f and .e are considered as floats but .a thru .d and .g thru .z all work fine in my experience with v1.46.
Posted on 2003-05-22 09:27:50 by revolution