flat assembler
Message board for the users of flat assembler.
Index
> Main > Understanding fasm (draft) Goto page 1, 2 Next |
Author |
|
Tomasz Grysztar 24 Jan 2006, 22:45
Recently, while I was writing some additions to the manual, came to my mind the idea of defining and describing some overall characterstics of fasm's language. I already wrote the "Design Principles", which explain how it happened that some of the things in fasm were done the way they were, however what I'm hoping to do this time, is to write something finally arranged, from the current point of view (after six years of development), which would summarize its design and rules, especially those features, that may be confusing because of failing to conform with the expectations. Most of such problems arise from the fact of assembly language having some layers - which in case of fasm are more distinct than in case of classic assemblers.
[edit]This text has been moved to the Documentation section.[/edit] Last edited by Tomasz Grysztar on 18 Mar 2006, 18:43; edited 18 times in total |
|||
24 Jan 2006, 22:45 |
|
revolution 27 Jan 2006, 00:43
While I understand all that you are saying above I just can't seem to grasp what point you are trying to make with it. Are you trying to get people to think in two different mindsets when writing the files intended for FASM to process? I think it might more important to explain the things like rept/repeat and equ/= differences, this always seems to cause confusion for new comers. In another thread you posted a very good table showing at which processing stage various things were done, and sorry to repeat myself, but tables like that are much better at showing a concept than sentences of English (or any text language).
|
|||
27 Jan 2006, 00:43 |
|
RedGhost 27 Jan 2006, 01:01
revolution wrote: more important to explain the things like rept/repeat and equ/= difference that is explained in the documentation, this is more a guide to fasm-style assembler i believe _________________ redghost.ca |
|||
27 Jan 2006, 01:01 |
|
okasvi 27 Jan 2006, 01:37
wow, the example in "Using flat assembler as pure interpreter" was really nice
i didnt know fasm would be able to do something like that _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
27 Jan 2006, 01:37 |
|
chris 27 Jan 2006, 05:35
needless to say, fasm is designed to be a assembler(a translator of assembly language to machine code). However, the power of fasm is far beyond an ordinary assembler, which makes it different. From my point of view, it's more like a scriptable/programmable command interpreter with its emphasis on binary file generation.
|
|||
27 Jan 2006, 05:35 |
|
revolution 27 Jan 2006, 05:41
Quote:
|
|||
27 Jan 2006, 05:41 |
|
Tomasz Grysztar 27 Jan 2006, 07:51
revolution: no rush, this is just the beginning of text, I'm going to covert the preprocessor layer and its separation from the other ones a bit later, after I get interactions between various layers in assembler itself cleared. Actually the thing with preprocessor is much more simple and the single table like that is able to explain the most of it. The layers within assembler itself is a much more delicate concept.
revolution wrote: Yes, of course it is but it seems not to be clear because so many people get tripped up on exactly these things. This is more because: a) people are used to different behavior of other assemblers, where macroinstructions and EQU are the directives of the same layer as any other assembler directives (the only one interpreted layer in such case); b) they don't read the documentation, with the assumption that they already know what macroinstructions and EQU do, as they used them with other assemblers; or c) they don't read the documentation; for any other reason why people usually don't read the manuals. I wrote the fasm's manual to be more like continuous text that has to be read consecutively instead of simple reference, hoping to force this way people to read a bit more instead of just the information on the single feature they're looking for. |
|||
27 Jan 2006, 07:51 |
|
vid 27 Jan 2006, 09:19
Tomasz Grysztar wrote: I wrote the fasm's manual to be more like continuous text that has to be read consecutively instead of simple reference, hoping to force this way people to read a bit more instead of just the information on the single feature they're looking for. btw, i noticed that this approach causes problems when anyone gets to "instruction" part, he thinks "i don't need to read instruction reference" and ends, without reading the most important things behind it. I've seen few such cases here. |
|||
27 Jan 2006, 09:19 |
|
Borsuc 28 Jan 2006, 11:28
vid wrote: btw, i noticed that this approach causes problems when anyone gets to "instruction" part, he thinks "i don't need to read instruction reference" and ends, without reading the most important things behind it. I've seen few such cases here. maybe try to put instruction reference in appendix like Nasm doc? btw: nice guide. definetely help newbies to Fasm understand that it's different from other assemblers. |
|||
28 Jan 2006, 11:28 |
|
Tomasz Grysztar 28 Jan 2006, 13:35
Even the x86 instructions section itself is very important, and not reading it causes many problems about syntax, like with the operands for XLAT or MOVS, using segment prefixed adresses, FPU instructions syntax - there are everywhere some small issues, and that section was in fact not written to be really a reference (as for instruction reference you've got the complete Intel or AMD manuals), but primarily to clarify syntax that fasm uses for every single instruction. Even when knowing some general rules, there are still many settings for the instructions that are quite specific and not always conforming to other assemblers. Like the XLAT and string instructions (where I followed the TASM's syntax), or the jumps like:
Code: jmp pword 0:0 (in NASM you'd write "dword", here's the difference). And FPU instructions... that's a true mayhem. |
|||
28 Jan 2006, 13:35 |
|
revolution 28 Jan 2006, 15:39
Quote: This is more because: Quote: b) they don't read the documentation, with the assumption that they already know what macroinstructions and EQU do, as they used them with other assemblers; Quote: or Quote: I wrote the fasm's manual to be more like continuous text that has to be read consecutively instead of simple reference, hoping to force this way people to read a bit more instead of just the information on the single feature they're looking for. Don't get me wrong, I think what you are trying to achive with the documentation is a great thing. An I hope that you understand I am just trying to offer some different perspective from a users point-of-view. For myself and my style of doing new things, I like to "do it" first and if I fail then check the manual on the parts I am having trouble with. How many people here can truthfully claim to read the entire DVD player/TV/whatever manual first before plugging it in and watching something. |
|||
28 Jan 2006, 15:39 |
|
Tomasz Grysztar 28 Jan 2006, 16:28
I agree that some table-based reference documentation would make a good addition to the existing one - for the quick reference (though perhaps at price of the completness). I may go no with writing such when I finish what currently pushes me from inside of my head, restlessly awaiting for finally becoming put down in text.
|
|||
28 Jan 2006, 16:28 |
|
okasvi 28 Jan 2006, 16:42
revolution wrote: For myself and my style of doing new things, I like to "do it" first and if I fail then check the manual on the parts I am having trouble with. While coding I always have fasm.pfd open so I can just quickly alt+tab and search for some instruction/whatever to look for help and its not even rare that I have to open up like 10 of my old sources to remember how to do that and what is the api for this and that etc. If I'm honest I cant even remember how to define a code/data section so I always copypaste it from win32ax.inc because its always already open due some error while compiling and my mouse(mx1000) does have buttons for copying/pasting ToDo: ;
focus on it memorize it jmp ToDo _________________ When We Ride On Our Enemies support reverse smileys |: |
|||
28 Jan 2006, 16:42 |
|
r22 29 Jan 2006, 06:11
Another thread tangent.
http://developer.amd.com/devtools.aspx At the bottom of this page it lists NASM and YASM as suggested free assemblers to use. If you feel as I do, that FASM should be on that list, then make sure to click on the "Contact Us" link at the bottom of the page and voice your opinion to AMD. |
|||
29 Jan 2006, 06:11 |
|
Madis731 29 Jan 2006, 10:22
I hope this reply goes under the section - understanding FASM:
I've done programming in every corner of the CPUs silicon, but the FPU gets me confused. I can accomplish my task finally, but it seems that FASM isn't sure what it expects from me. I can't tell from the errors if the short-form instruction isn't supported or does it just ignore my request for the parameters like st0,st(0),st... I usually got to the st(0..7),st(0..7) solution, if the short form isn't supported (like the FMUL(P)) but there is no easy way to tell where the problem came from. I don't know if this is what you meant with the mayhem but it really is. I usually couple OllyDBG with my executable to see what the instructions do, because it isn't easy to memorize everything |
|||
29 Jan 2006, 10:22 |
|
Tomasz Grysztar 29 Jan 2006, 10:27
Actually the rule is simple (I have taken this from the recent Intel manuals, not looking at other assemblers): only the popping instructions have the short forms. So "fmulp" and "faddp" can be assembled without any operands, while "fadd" and "fmul" need the operands every time - and explaining what those operands should look like is exactly what the sections about instruction are there for.
|
|||
29 Jan 2006, 10:27 |
|
Madis731 29 Jan 2006, 10:55
Okey, that makes it clear - sorry I didn't figure out the logic myself. Just there are a lot of different sources on the net
About the draft at the beginning of this thread. Its easy to understand and helpful but maybe too easy reading if you know what I mean Maybe shorter text (with the set-back of more difficult to read text). |
|||
29 Jan 2006, 10:55 |
|
Tomasz Grysztar 29 Jan 2006, 12:43
Almost finished the part about code resolving - perhaps now it will be time to complicate things even more and introduce preprocessor layer.
|
|||
29 Jan 2006, 12:43 |
|
Madis731 29 Jan 2006, 13:53
Erm, I just read it and it really is complicated:
Code: dd x,y x = (y-2)*(y+1)/2-2*y y = x+1 ;What does the FASM do first? My best guess is: ;x=0, y=0 then find out if it is correct... x= (0-2)*(0+1)/2-2*0 = -1 y= 0+1 = 1 ;In the next pass: x= (1-2)*(1+1)/2-2*1 = -3 y= -1+1 = 0 ;Another pass? x= (0-2)*(0+1)/2-2*0 = -1 y= -3+1 = -2 ;The 6 is resolved, but: x= (-2-2)*(-2+1)/2-2*(-2) = 6 y= -1+1 = 0 ;Yet another??? x= (0-2)*(0+1)/2-2*0 = -1 y= 6+1 = 7 ; x= (7-2)*(7+1)/2-2*7 = 6 y= -1+1 = 0 ; x= (0-2)*(0+1)/2-2*0 = -1 y= 6+1 = 7 |
|||
29 Jan 2006, 13:53 |
|
Goto page 1, 2 Next < Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.