flat assembler
Message board for the users of flat assembler.

flat assembler > Compiler Internals > [fasmg] small error in line continuation with comments

Author
Thread Post new topic Reply to topic
bitRAKE



Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
Just expanding the example from the manual and adding a comment to the end of line caused an error:
Code:
        iterate <name,value>, \; comment
          a,1, \
          b,2, \
          c,3
                name = value
        end iterate
    
Seems like a weird corner case, but I really do like to split these lines and comment. Very Happy Using version g.ibh5n which is the most recent I see. Or, maybe this is no longer possible?

_________________
unlicense.org
Post 04 Dec 2018, 00:44
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7001
Location: Kraków, Poland
I broke it when I implemented RETAINCOMMENTS and ISOLATELINES. Thank you for letting me know, it should be fixed now (g.idtrm).
Post 04 Dec 2018, 07:54
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
Would you mind if I completely rewrote map.inc? Or should a just post small changes, like line 161, should remove implied lock on xchg:
Code:
        mov     edx,[ebx+Map.linked_blocks]
        mov     [ebx+Map.linked_blocks],eax
        mov     [eax],edx    
...and I could refactor destroy_string_map to:
Code:
destroy_string_map:
; in: ebx - map
; preserves: esi, edi

@@:     xchg eax,ebx
        mov ebx,[eax] ; Map.linked_blocks must be first element
        call mfree
        test ebx,ebx
        jnz @B
        retn    
Code:
hash_string:
; in: rsi - string, rcx = string length, zero for ASCIIZ string
; out: rcx = string length, edx = 32-bit hash
; preserves: ebx, esi, edi
        mov edx,FNV_OFFSET
        push rsi
        jrcxz hash_asciiz
        push rcx
    hash_known_length:
        lodsb
        xor dl,al
        imul edx,FNV_PRIME
        loop hash_known_length
        pop rcx
        pop rsi
        retn

    hash_asciiz:
        lodsb
        xor dl,al
        imul edx,FNV_PRIME
        inc ecx
        test al,al
        jnz hash_asciiz
    hash_ready:
        pop rsi
        retn    
...etc.
Post 10 Dec 2018, 07:05
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7001
Location: Kraków, Poland
I don't mind improvements to this code, especially considering that MAP.INC was the very first set of routines I created when started implementing fasmg, because I needed it for source cache in the beginning. For this purpose the performance was not important and the code was left mostly unchanged, according to the rule of "not fixing what is not broken". Though after all I ended up using it in a few more places (in addition to original source cache), so perhaps it could be worth improving... Did you notice any gain in regular fasmg use with your corrections?

bitRAKE wrote:
Code:
        mov ebx,[eax] ; Map.linked_blocks must be first element    
With the style conventions I use in fasmg sources this should look like:
Code:
        assert  Map.linked_blocks = 0
        mov     ebx,[eax]       ; [eax+Map.linked_blocks] in the first run    
Post 10 Dec 2018, 10:20
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
I wasn't really thinking about performance. It was more like "low hanging fruit". Seemed rather contained with little chance of me breaking something else. Hopefully, I will get more comfortable with the source and the style.

With regard to XCHG, modern processors will only lock the cache if the data is in the cache. So, I doubt it will have much impact in the present use.

Something else I noticed: hash_string includes the terminating zero in the hash of a string only when the string length is not provided. Assuming the zero isn't counted in the length. Therefor a use case exists where the same string could return different hashes. Obviously, this doesn't happen in FASMG - otherwise it wouldn't work. Does the design require the inclusion of the terminating null?

(So, far I think that it does. Appears to be only two uses which pass ECX: use_source counts the null, format_binary is a little harder to understand. All the others use the asciiz branch and hash the null.)

Maybe, I'm wrong, but I think hashing the null on strings weakens the low order bits of the hash - which is relied on by the map. Seems easy enough to skip it - I'm tracing down the length returned to see if that will create a problem.
Post 10 Dec 2018, 15:24
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
Rather than pondering here further, I tried some things.

My discovery is that strings aren't always strings. Yet, if I keep the null in the length everything appears to work okay. So, hashing without the null is fine because non-strings are always processed with their length. The converse is not true - some strings are not null terminating - which is strange.

Since it's working then I'm assuming there is another class of strings which are always called with their length, and they would never match regular null strings. File extension is one case, and number strings another.
Post 10 Dec 2018, 22:48
View user's profile Send private message Visit poster's website Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 2672
Location: dank orb
So far I've been able to slow it down by 5% with very small changes. Razz

_________________
unlicense.org
Post 11 Dec 2018, 05:01
View user's profile Send private message Visit poster's website Reply with quote
Tomasz Grysztar
Assembly Artist


Joined: 16 Jun 2003
Posts: 7001
Location: Kraków, Poland
Yes, in general any given map either always uses explicit length [byte strings] or always NULL-terminated ones. Because the two kinds are never mixed within the same map, this did not manifest as a bug.

The terminating zero needs to be counted into length, because when such string needs to be copied elsewhere (to a string storage), the terminating zero needs to be copied as well.
Post 11 Dec 2018, 06:43
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2018, Tomasz Grysztar.

Powered by rwasa.