Index
> Compiler Internals > [minor bug]Code resolving not minimalGoto page 1, 2 Next |
| Author |
|
|
revolution 24 May 2006, 14:47
One more thing that may help is this:
Code: use32 a: mov eax,[edx+c-a-5] mov esi,[edx+c-a-5] c: Gives an error that code cannot be generated, but it can be resolved like this: Code: use32 a: mov eax,[edx+c-a-5] ;8B 42 01 mov esi,[edx+c-a-5] ;8B 72 01 c: |
|||
24 May 2006, 14:47 |
|
|
LocoDelAssembly 24 May 2006, 17:07
The last one works for me. I'm using 1.66 which I downloaded before your previous bug was fixed, I forgot to download the fixed version
 |
|||
|
24 May 2006, 17:07 |
|
|
Tomasz Grysztar 24 May 2006, 18:04
As you can conclude from the "Code Resolving" section of Understanding fasm article, the only thing that you can be sure with it (unless there are some bugs, of course
 ) is the correctness of generated code if assembler succeeds to find such solution. Neither the minimal size nor the ability to find the solution can be guaranteed in general case. |
|||
|
24 May 2006, 18:04 |
|
|
LocoDelAssembly 24 May 2006, 18:25
revolution, now I also tested your last code with the 19-May-2006 version and works fine too :S
|
|||
|
24 May 2006, 18:25 |
|
|
vid 24 May 2006, 21:10
anyway, revolution, thanks for idea. I am sure Tomasz spent more time over this than he revelealed
|
|||
|
24 May 2006, 21:10 |
|
|
Tomasz Grysztar 24 May 2006, 21:47
Not really - at least yet - as I had no time for this.
However my answer above I could base even solely on the title of this topic.
PS. However I forgot to mention the section 2.2.6 of manual, which is also important here (perhaps even more than the link in my above post). |
|||
|
24 May 2006, 21:47 |
|
|
revolution 25 May 2006, 01:49
Quote: The last one works for me Hmm, you are right. I actually had this below but edited out the unused label b, I thought it would make no difference. Code: use32 a: mov eax,[edx+c-a-5] b: mov esi,[edx+c-a-5] c: Quote: Neither the minimal size nor the ability to find the solution can be guaranteed in general case. |
|||
|
25 May 2006, 01:49 |
|
|
Tomasz Grysztar 25 May 2006, 09:38
Any update of resolving algorithm would have to be extremely careful, since it's very easy to make some new code to resolve nice for a price of loosing already-existing good resolving of some other code.
I'll see however, if I can do anything about it without breaking what's already achieved. |
|||
|
25 May 2006, 09:38 |
|
|
Tomasz Grysztar 30 Mar 2009, 07:26
I forgot about this thread, but perhaps I should add at least some more detailed explanation.
When assembler encounters in a numerical expression a symbol, whose value it haven't yet seen at all (this occurs only in the very first pass for the forward-referenced symbols; in later passes the value from previous pass is used for predictions), the whole expression is predicted to have zero value (this helps to pre-generate the shortest possible opcodes). So, in case of this code sample, both instructions are in first pass generated as short ones (with displacement 0). This causes "c-a" to have value 4 predicted in the next pass and therefore both instruction are now generated as longer. Therefore fasm can never hit the "right" 5 bytes solution. Anyway, you can use some ugly trick to help fasm with this puzzle: Code: use32 L = c-a-5 a: mov eax,[edx+L] mov esi,[edx+L-2] c: Now in first pass L gets value of 0 (because it contains unknown value c), so the first instruction is generated as short, but the second one as long. So in the next pass "c-a" is predicted to be 5, and thus L again gets predicted value of 0, everything fits and assembler happily finishes with this solution. |
|||
|
30 Mar 2009, 07:26 |
|
|
Tomasz Grysztar 30 Mar 2009, 07:37
As for the second, it is caused by the "optimization adjustments" mechanism (defining additional label inbetween causes the adjustments to be updated, in this case with a poor consequences for the assembly process). I may forge some detailed explanation later.
As I explained above, I don't consider these a bugs, really - it is not possible to make an algorithm that would work for all cases, so such things must happen with some pieces of code. If we call them bugs, then fasm is going to be inevitabily bugged with no possible fix in any future. Last edited by Tomasz Grysztar on 30 Mar 2009, 07:38; edited 1 time in total |
|||
|
30 Mar 2009, 07:37 |
|
|
revolution 30 Mar 2009, 07:38
Your trick if fine IF we know the values at the time of writing. But often these values are symbolic constants or generated by expressions further down the code (and many other ways of obscuring the values from the programmer). But it does serve a nice little example of how to help fasm with some aspects of code generation.
|
|||
|
30 Mar 2009, 07:38 |
|
|
Tomasz Grysztar 30 Mar 2009, 07:42
You may land at the trick with the experimenting - when with large code you get "cannot be generated" and don't know what's going on inside, you may as well play with some constants and get the right solution, without even knowing what is going on inside there. The only thing fasm guarantees to you is that when it says the code has been generated, it is going to be the correct solution.
As I said - I could perhaps modify the optimization algorithms to deal correctly with the above samples, however this way I would break them for the cases of more usual code, for which they were designed. That's not the way to go. |
|||
|
30 Mar 2009, 07:42 |
|
|
revolution 30 Mar 2009, 07:46
Tomasz Grysztar wrote: As I said - I could perhaps modify the optimization algorithms to deal correctly with the above samples, however this way I would break them for the cases of more usual code, for which they were designed. That's not the way to go. |
|||
|
30 Mar 2009, 07:46 |
|
|
Madis731 30 Mar 2009, 12:44
@revolution:
 |
|||
|
30 Mar 2009, 12:44 |
|
|
Luc Van de Velde 30 Mar 2009, 17:36
sorry to disappoint u revolution... but rasm uses the same basic optimizing principles as fasm (which are perfect and cannot be improved)
its true that u can design code samples that are not optimized perfectly i am not bothered with this, coz as thomas said 'it works in normal cases' thomas would be right not to bother trying to improve fasm in this regard a solution would require too much math... and thats not good for assembly speed... u should try to introduce more usfull functionallity |
|||
|
30 Mar 2009, 17:36 |
|
|
revolution 30 Mar 2009, 17:40
Luc Van de Velde wrote: sorry to disappoint u revolution... but rasm uses the same basic optimizing principles as fasm (which are perfect and cannot be improved) |
|||
|
30 Mar 2009, 17:40 |
|
|
Tomasz Grysztar 30 Mar 2009, 17:42
Luc Van de Velde wrote: (...) the same basic optimizing principles as fasm (which are perfect and cannot be improved) I think that's a little exagerration. |
|||
|
30 Mar 2009, 17:42 |
|
|
Madis731 31 Mar 2009, 09:34
Tomasz Grysztar wrote:
...but still a nice pat on the shoulder 
PS. Actually I do believe P=NP (I've been dreaming about TSP-problem) and I will tell you if I find a proof |
|||
|
31 Mar 2009, 09:34 |
|
|
Luc Van de Velde 01 Apr 2009, 19:33
what u mean by quote 'outside of the fasm project' are there more important things in computer sceince than developing a good computer language (assembler based offcourse) and teaching others how to solve often very complex problems with it?
an assembler is not an equation solver... if thats what u are after revolution... mathlab can do that just fine... i wonder if an assembler should have an equation solver... what do u think about this tomasz? personaly... i dont deal with that kinda complex equations (yet) I use rasm to develop circuits for my own x86-compatible cpu... i really need that |
|||
|
01 Apr 2009, 19:33 |
|
| Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|