2Tomasz Grysztar: You did not reflect to make native x64-bit version of FASM? And it is how much difficult to make such adaptation?

this thread shouldn't be posted here, moderator, please move it

Garthower: it will need complete code rewrite, so i don't see it very realistic

Excuse me, probably I was mistaken. In what subjects there should be this thread?

i would place it to Main, or maybe Compiler Internals (but rather Main).

anyway, you can't move it now, it must be moderator.

it's okay, it's just that "Project and Ideas" means more like "Project and Project Ideas"

Well, I have understood, thanks. But all is a pity that to make native x64-version of FASM isn't absolutely realistic

Garthower - the thing is that it works on a 64-bit machine without any trouble. The 64-bit world wouldn't give it an enormous speed jump either because there aren't many things you can do faster with wider registers. Vid is right, you would have to re-write all the code.

And it would certainly eat up much more memory when changing from 32-bit pointers to 64-bit ones.
On the other hand, the expression calculator would be easily adapted to do 128-bit computations on change to use the wide registers, as they are 64-bit right now. But that would be perhaps the only possible advantage.

Well, specifically more registers mean less memory usage (as in stack and pushing and popping) so one slight advantage would come from that fact. Still it can't be done simply with macros, but should be hand-written once again.

The heavy use of pointers in all the fasm's data structures would cause much larger growth of memory usage than what you would gain thanks to more registers.

The question is this:
What are you hoping to accomplish?
(a) SAVE memory (as if we are living again in 1959)
(b) SAVE execution time (as if we are using the 80286, blazing along at 4 megahertz)
(c) WRITE code quickly--i.e. ostensibly saving your time
(instead of authoring a PROGRAM, readable, autodocumenting, by virtue of NOT using pointers-->instead using registers, (and, HORRORS, FIXED, known addresses!! zounds, sacrilege, get ye hence, demon!) something not available 25 years ago, when dynamic pointers were deemed irreplacable.)

You prefer wasting memory and execution time, and writing code slowly?
If the result is good (and maintainable), then where is the problem?

There is nothing better than fast, small, maintainable application, which FASM is. Even if it uses something you do not like, and even if you don't consider it to be a program.

Well, maybe due to your definition FASM isn't PROGRAM, but it still does it's job better than any "PROGRAM" would. It isn't goal to make a strict-by-some-definition "PROGRAM", goal is to have tool that is good-working (fast 'n' small, easily fixable). "PROGRAM" is just one way how to easier accomplish these goals, not goal itself, nor ultimate only-one way how to accomplish them. If someone can do it better and other way, then it's fine.

And one question - how would YOU make FASM's finding directive/instruction handler without pointers? I mean that table with directive names preceded by pointer to handler routine. Will you prefer case command with ~1000 cases (MUCH more readable by the way...)?

Didn't mean to offend you Vid, but, in my opinion, maybe an opinion shared by no one else, there IS something superior to "fast, small, ..." and that is:
READABLE. In my opinion, READABILITY trumps ALL ELSE. Not speed. Not saving memory, not time to implement. FASM is unreadable.
To answer your question:

No, I do write slowly, because I am not clever. However, it is not my goal to write slowly. It is my goal to end up with a PROGRAM, not code, that is READABLE, i.e. understandable to someone who has NOT participated in the task of implementing the algorithm.
Nor is it my intention to "WASTE memory", but it IS my goal to USE memory, and not guard it like some kind of precious metal, sitting in a bank vault.
As far as execution time, I doubt that an application as small as an assembler will execute signifantly SLOWER if the source code employs registers and named data structures instead of unnamed, dynamically generated pointers. I am willing to concede that pointers may indeed be FASTER, I am not sure of that, but it is irrelevant to me, I will concede that they may well be MUCH faster, maybe even 10 times faster, SO WHAT??? Why is that important? Why adopt a 1980's definition of "optimization", instead of 21st century view? What counts, is not how many milliseconds faster FASM assembles when using pointers instead of named data structures, or how much less memory FASM uses in performing its assembly of source text, what counts is DOCUMENTATION, CLARITY of the code, and READABILITY, so that FASM could be modified to suit changing needs. That this debate is not merely nonsensical ramblings, but very appropriate and timely, one need simply consider the origin of this thread seeking information on modifying FASM to accommodate 64 bit applications, and your comment, Vid,

and, so, actually, one could rename this thread:
FASM2
And like most things in life, a second iteration often represents some improvement. I am asking Tomasz to answer these three questions, here, I will repeat them:

since, I now envision a day, in the not distant future, when Tomasz will indeed decide to completely revise FASM, i.e. start anew. And, when that happens, it might not be a bad thing to commence with an overview, a design document, something that expresses the overall architecture, BEFORE the code is written. That approach, of course, represents the "slow" method, much maligned on this forum.

1. you didn't answer this:

2. I am afraid you are missing POINT of programs. Programs are not written te be readen by others, they are written to serve that purpose (except some minor university stuff). And in our problem, programs that are written "badly" in your opinion, serve this goal better.

Do you write programs to be used, or to be readed?

[edit] 3. I remember you was talking about making some FFT-based things like speech recognition etc. I believe this is extremely CPU time consuming. What is better for normal people, to have sources of your speech recogniser (which you don't have) readable, or to waste 10% CPU instead of 40%?

[edit 2] 4. FASM source is IMO very readable, but of course you must read it in language it is written in - that is assembly. Of course it isn't readable "in english"

mov ah,9
mov dx,_passes_suffix
call dos_int
xor ah,ah
int 1Ah
mov ax,cx
shl eax,16
mov ax,dx
sub eax,[start_time]
mov ebx,100
mul ebx
mov ebx,182
div ebx
or eax,eax
jz display_bytes_count
xor edx,edx
mov ebx,10
div ebx
push edx

If my life depended upon it, I could not explain what this code fragment is supposed to accomplish. I did not remove the comments--there simply are none.
Is it well written? I don't know. Is it concise? I don't know. Is it efficient? I don't know. Could it be improved?? I haven't the slightest idea....I am so ignorant here, and so completely lost, that I cannot, for example explain to someone why XOR is used to clear edx, but OR is used for eax. For all I know, "OR" represents a typographical error, and it should be XOR, instead???? I have no idea why edx is being pushed, but not ebx. I don't know why edx is being pushed onto the stack instead of being assigned to a variable....Is shl eax,16 intended as a multiplication, or some kind of exchange operation? I surely haven't the foggiest notion of why one needs to divide 182 in ebx? Why is there only one operand in mul ebx? What happens to the product?

Emm. Hmm. Errrr, ah, hmm. Well, let's see, how to begin? Yes, it is not readable in English. I agree with you. But, should it be? Should one be able to take a fragment of FASM, any old 20 lines of code picked at random, as this fragment is, and explain:
What it's purpose is,
Why it is written the way it is, i.e. using those particular instructions, rather than some others.
How this fragment integrates with other modules....
I guarantee if you will look at Dandamudi's book, you will find well written, and well explained PROGRAMS. And yes, they are written in English, and no, I am not sure whether or not, the late professor Dandamudi's mother tongue, was English.

A quarter century ago, I wrote programs, (inferior to most of those I see on this forum,) which were intended to be used--not read, and most of which represented a cacophony, not a symphony.

Yes, this is a common misconception. In my research, I found that my own FFT, approximately twice as fast as the "Really FAST FFT's" reported in Dr. Dobb's software journal, more than a decade ago, required less than 5% of the cpu (486), as I reported in the proceedings of a digital signal processing conference held in SanJose in 1993. The FFT, a precise mathematical solution, does not require the same detailed explanation as some very NON-numerical application, like an assembler. Most of my code is just that: CODE, i.e. transcendental operations, sines, cosines, etc. That doesn't excuse my sloppy writing, and surely my criticism of Tomasz' effort applies 100% more to my own situation, so I am not touting any supposed accomplishments by me (for there surely are none to boast about, else rest assured, they would be posted here every day!!!) as an illustration of how one OUGHT to program, no, I admit I lack the skill to program. I am only a coder. And a mediocre one at that. But, in my opinion, most of the folks on this forum are VERY skillful, and therefore, OUGHT to be trying to improve their programming ability.
What that means, in concrete terms is this:
1. start with an overview document that explains one's goal, and
2. how that goal will be accomplished, specifically, which:
a. data structures are required, and
b. what kind of program flow is envisioned.
AFTER this overview document is authored, THEN one commences with writing CODE, which, MUST, to be a program, then be explained, if not line by line, at least section by section. A couple dozen lines of undocumented code, such as that included above, is illustrative of the antithesis of programming, i.e. code writing.
This is not some kind of "university" modus operandi. This is how one programs. This is not some kind of magic. This is how one writes programs, IN ANY LANGUAGE. If English is too obnoxious, write in some other language, and then someone else can translate.

If you're asking for code readability on an x86 assembly forum, you're in the wrong place.

People don't program in assembly for code readability. That's what C++ or some other high level language is for.

line by line documenting is not very useful most of the time, especially not in assembly where you have a lot of lines... except, sometimes, when explaining complex optimizations.

But some brief "per-block" comments are often a good thing, and for non-trivial larger-than-tiny projects, some external documentation (aka "The Plan") is a good thing (if not a must).

The FASM source is, imho (and no disrespect meant) somewhat of a "mind flush" - but it's pretty clean for such a mind flush. I've seen cleaner code, I've seen worse code. There's a bit too many magic numbers for my liking, and it would be nice with a few comments here and there... and you really need some fileformat references if you look at the output formatters, things like that.

Then there's small nitpicks like "test reg, reg" being a bit more intuitive than "or reg, reg" (or is, logically, a modifying instruction), but that really is nitpicking. I have no gripes with "xor reg, reg", though, since that's been a common defacto accepted way of clearing registers on the x86 since the beginning of time

But even if the FASM source is in some way a bit messy, it still comes off as a lot cleaner than much other stuff I've seen. I'm not sure exactly what does it... perhaps that Tomasz had an idea/strategy/plan while he wrote it. And that it's relatively modularized.

Well, any programming I do for fasm project indeed starts with designing the data structures and program flow, however the most of time everything happens inside my head. Sometimes I write down data structures and algorithm diagrams on paper, but this is like making a first sketch before finally putting the paint to the canvas - it is not what I would like to be seen in final, the actual paint replaces it. And the most of actual "painting" still comes directly from my head. And for myself fasm is still more a work of art than a "product" (and thus, of course, you're free to judge it on any terms you want, really - just there may happen some misunderstanding from the fact that, as they say, "de gustibus non est disputandum" ).

PS. This all shall also explain why I indomitably keep fasm as the "one-man project".

"In matters of taste, there is no argument"
Actually, this introduces a new topic, twin studies, in which identical twins were separated at birth, and raised in different homes, distant from one another, without any communication, or even knowledge of the other's existance, until adulthood, and when tested, for the sense of taste (gustation), it was then understood, that there is more genetic control of sensory input (and conversely, much less influence by the environment) than had been anticipated, so, even something as apparently innocuous as a Latin phrase, may be challenged. One CAN dispute EVEN taste, notwithstanding the famous Latin aphorism, quoted by Tomasz, attesting to the contrary.

fine. end of story.
Garthower had asked, to start this thread, :

and the answer is:
fasm is a work of art, and therefore, it can or will be changed, as the mood of the artist wishes....
Fine.
No problem, BUT,
Then, I don't want to read any more crap, from anyone, defending this supposedly (according to Vid, at least)
spaghetti paint and pastels, with some watercolors mixed in for good measure. No need any further for this kind of excuse, fudder:

Is Guernica relatively modularized? How about Nightwatch?
http://www.gbg.bonet.se/3dcastle/castle/nightwatch.htm
How about Le Dejeuner sur l'herbe?
http://www.artchive.com/artchive/M/manet/manet_dejeuner.jpg.html

Whether it is modular, or readable, or possesses or does not possess, ANY feature, any parameter by which software is judged, IS IRRELEVANT. It is an artistic endeavor, and therefore, NOT AMENABLE to conventional analysis. That is why Tomasz has no need to answer my three questions above. They are irrelevant too. Does one ask Picasso to explain why he chose to portray the tiny village of Guernica as a symbol of fascist military aggression, instead of some other metropolis?
Tomasz is correct, FASM is his artistic accomplishment, and his alone, and he has no need to explain any part of it, to anyone. Garthower's question is moodt. FASM will change if and when the artist wishes. But, please, now that we all understand the situation, please stop with the mindless chatter endlessly praising the King's vesture. He has no clothes.

I used to comment my programs, because it makes work easier after a long time.

Every 'serious' and complicated procedure or program I write on paper first. I often make a flowcharts. After several verifications I copy ready assembler code and... run it.

It is a hard work, but effective and makes me sure, that programs written that way are faultless.

Regards,
M.H.

... okay, shortened this answer to minimum:

You are blaming our programs for not being readable to you, but you don't know the language they are written in.

One more example to finish: Other people, who know the language, can read "FASM program". You can't. Does this mean that it's unreadable, or that you can't read?