flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
AsmGuru62 22 Nov 2011, 18:09
Interesting..., but can you find any FASM bugs in a "real" code samples?
By this I mean the code wich runs and produces some results - a real program and not 'research' type code. |
|||
![]() |
|
ouadji 22 Nov 2011, 20:11
yes,but there are no differences with the first example. A small part of the current version of Wink (7800 lines of code) Code: label GL_As dword ; first AGIa dd ? AGIb dd ? AGIc dd ? AGId dd ? AGIe dd ? AGIf dd ? AGIg dd ? AGIh dd ? AGIi dd ? AGIj dd ? AGIk dd ? AGIl dd ? AGIm dd ? AGIn dd ? AGIo dd ? AGIp dd ? AGIq dd ? AGIr dd ? AGIs dd ? AGIt dd ? AGIu dd ? AGIv dd ? AGIw dd ? AGIx dd ? AGIy dd ? AGIz dd ? AGI@ dd ? ;--- specific Polish characters AGI_A5 dd ? AGI_C6 dd ? AGI_CA dd ? AGI_A3 dd ? AGI_D1 dd ? AGI_D3 dd ? AGI_8C dd ? AGI_8F dd ? AGI_AF dd ? AGI_B9 dd ? AGI_E6 dd ? AGI_EA dd ? AGI_B3 dd ? AGI_F1 dd ? AGI_F3 dd ? AGI_9C dd ? AGI_9F dd ? AGI_BF dd ? AGI_01 dd ? label GL_Ae dword Dim_AGL = (GL_Be - GL_Bs) ;<--------------------- !!! Dim_AGL_dd = Dim_AGL/4 Dim_RAZ_dword = ($ - start_address_RAZ)/4 sizeof.raz_initial_startup = ($-raz_initial_startup)/4 label GL_Bs dword dd Dim_AGL_dd dup ? label GL_Be dword Code: bt [Tflag],0 jc back_T mov eax,Tpile_S mov [eax],esp mov esp,eax push ebx push edx push esi push ebp mov ecx,sizeof.vOS-4 push_vOS: push [var_OSs+ecx] sub ecx,4 jns push_vOS mov ecx,Dim_AGL-4 ;<----- ecx = 0-4 = -4 !!! push_GLA: push [GL_As+ecx] sub ecx,4 jns push_GLA mov ecx,Dim_AGL-4 push_GLB: push [GL_Bs+ecx] sub ecx,4 jns push_GLB mov esp,[eax] back_T: |
|||
![]() |
|
Tomasz Grysztar 23 Nov 2011, 00:03
ouadji wrote:
|
|||
![]() |
|
ouadji 23 Nov 2011, 00:50
I'm not agree with you. It's not because fasm finds a "valid" solution that there is no error. if A=f(B) and B=f(A) ... there is necessarily an error from the programmer. it is abnormal to define "A" according "B", and "B" according "A". Fasm should at least report a warning. for example: warning at line x - cross-references |
|||
![]() |
|
Tomasz Grysztar 23 Nov 2011, 11:13
If you do not want to read the whole article, at least look at this: http://board.flatassembler.net/topic.php?t=4703
|
|||
![]() |
|
ouadji 23 Nov 2011, 11:44
Quote: If you do not want to read the whole article, at least look at this Of course i have read the whole article, (i almost feel like to do ![]() and i understand why Fasm finds a "valid" solution. What i say, it's abnormal to define A according B, and B according A. This, regardless of the program. In this case, there is a (very) high probability that the programmer has made a errors. The goal of a compiler is to compile, but also to help the programmer to find errors. And in this case, i think it would be nice that Fasm reports a warning. Last edited by ouadji on 23 Nov 2011, 23:42; edited 1 time in total |
|||
![]() |
|
l_inc 23 Nov 2011, 12:11
ouadji
You're wrong because it's not abnormal to use this fasm's quite practical feature. In fact it's very common "to define A according B, and B according A". The simplest example, I can think about is the following (16-bit): Code: @@: rb 126 ;could be any code of size 126 bytes jmp @B Here the size of the jmp instruction is implicitly defined by itself. Because if it's assumed to be 3 bytes long, than it cannot be reduced to a short jump, having the maximum jump length of 128 bytes. On the other hand if it's assumed to be 2 bytes long, than it can be resolved as a short jump. Because of the fasm's nice ability to silently converge to an (optimal) valid solution, the jump will be resolved as a short jump. Are you suggesting to report a warning also in this and many other reasonable cases? I find it irrational. |
|||
![]() |
|
shutdownall 23 Nov 2011, 12:28
ouadji wrote:
It depends on the function / relationship of A and B. In your example is A=B/4 and B=4*A. This is valid at least for all multiples of 4. You definition looks recursive at the first point of view and I wonder that FASM can resolve it. ![]() Anyway it does not make much sense to define structures this way because it's not unique. If there are many solutions for resolving it is correct to use any or the first solution. I think about doing my next tax declaration this way which hopefully could result in zero. ![]() |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.