Index
> Compiler Internals > Strange behavior of display directive when used with number |
| Author |
|
|
LocoDelAssembly 16 Nov 2008, 23:17
There are more problems
Code: ; This code takes some seconds to compile and then crash a = 0 ; also 1 and 2 takes time display a Code: ; This code keeps compiling endlessly display b Code: ; Crashes immediately a = 3 ; I've only tested a few numbers but seems that any number above 2 crash fast display a [edit]Now the second code doesn't keep compiling anymore but crashes instead so the behavior is random[/edit] |
|||
16 Nov 2008, 23:17 |
|
|
LocoDelAssembly 17 Nov 2008, 01:43
The following modification to ASSEMBLE.INC seems to solve the problem but you will have to wait Tomasz for the definitive fix
Code: display_directive: lods byte [esi] cmp al,'(' jne invalid_argument cmp byte [esi],0 jne display_byte inc esi lods dword [esi] mov ecx,eax push edi mov edi,[display_buffer] sub edi,8 sub edi,eax cmp edi,[esp] jbe out_of_memory mov [display_buffer],edi rep movs byte [edi],[esi] @@: ; Added label stos dword [edi] xor eax,eax stos dword [edi] pop edi inc esi jmp display_next display_byte: call get_byte_value push edi mov edi,[display_buffer] sub edi, 8+1 ; It was 4+1 before but show_display_buffer seems to wait for a two dwords structure always mov [display_buffer],edi stos byte [edi] mov eax,1 dec esi ; Added to compensate the "inc esi" above jmp @b ; Now I take advantage of the common code stos dword [edi] ; Obsolete pop edi ; code display_next: cmp edi,[display_buffer] ja out_of_memory lods byte [esi] cmp al,',' je display_directive dec esi jmp instruction_assembled [edit]I've added "dec esi" because fasm was incorrectly failing with multiple arguments with my fix[/edit] |
|||
|
17 Nov 2008, 01:43 |
|
|
koumes21 17 Nov 2008, 08:40
Thank you very much, it works fine. Now I will have a look at FASM source, I am interested how it works and I would like to be able to edit it myself in future.
|
|||
|
17 Nov 2008, 08:40 |
|
|
Tomasz Grysztar 17 Nov 2008, 10:35
I have fixed it with a silent update to 1.67.29 package, so do you don't have to wait for the next release.
 Just re-download. |
|||
|
17 Nov 2008, 10:35 |
|
|
LocoDelAssembly 20 Nov 2008, 01:05
Tomasz, could you start making your silent updates not so silent? Things like 1.67.29X where X is a letter from 'a' to 'z'. The problem, besides there are people that after finding a bug believes that they are using the latest version, is that transparent proxies won't allow people to download the latest ZIP because you name it exactly the same as the non-silent version.
Another thing, could you add in www.flatassembler.net/download.php "header('Cache-Control: no-cache')"? Although normally the way it is now is enough, I have seen some transparent proxies of my ISP caching even though there was no Last-Modified header to where apply heuristics to, and what was even worst is that them also ignore the Expires header. It is not happening in my zone anymore (or I'm very lucky by not hitting those configured that way), but other zones of the same ISP still have this problem which I don't know if this is the default settings of the BlueCoat appliances or yet another incompetence demonstration of the employees (well, leaving default settings blindly is also an incompetence demonstration  ).
Anyway, although perhaps that bad configuration is not very common among the transparent proxies around the world, from what I've understood from the RFC seems that the setting's behavior is backed by the RFC 2616 (even ignoring "Cache-Control: max-age=0") so you wouldn't change the script just for me . (I can get rid of this problem anyway but not everyone knows how to force the proxy to retrieve a fresh response)
Thanks Yes, I also think that Tomasz won't read this post for being unnecessary long but I have written it and I'll press submit anyway! |
|||
|
20 Nov 2008, 01:05 |
|
|
LocoDelAssembly 29 Nov 2008, 20:39
I guess this thread was sticky long enough already, the bug is fixed and the users should already noticed the silent update.
This thread is now a normal one again... |
|||
|
29 Nov 2008, 20:39 |
|
|
kas 30 Nov 2008, 04:57
When I ran into display problem... I just assumed that the display directive only 'did' strings! I didn't try it after that - not having much need to check strings...
...with numbers though - much more useful! 
Kas. |
|||
|
30 Nov 2008, 04:57 |
|
< Last Thread | Next Thread > |
Forum Rules:
|