Can we please get basic string concatenation operations so that it will be possible to mov ax,"A" + constant

TEST EQU "B"
mov ax,"A" TEST ; no can do

for example unix expression style string concat . operator "A".TEST will result in mov ax,"AB" this would leave + to be used for the arithmetical sum of hex values of "A" and "B". Or if using . would conflict too much with .labels then something. "A"&"B" ?

And can we please finally get an Intel strings directive!!! Meaning strings are assembled unchanged to register and LSB first in memory. This is one of the most serious Fasm issues to date. This is why the dw, dd datatypes are there to be used in the first place. If one wants a series of bytes one can always use db "ABCD" instead of dd "ABCD".

Tomasz it's fine if you like your strings mangled like they are now but can you please try to see the bright summer sun and understand that some other people would like to stick to the same convention that has been used since IBM PC came out 25 years ago and that all other tools like debuggers use. What do you think an asm coding veteran will say when confronted with Fasm source? Would "that's fucked up" be that far off?

Why don't you introduce two new directives, MSBSTRINGS and LSBSTRINGS . Then everybody would first of all know which they're using and finally

HAVE A CHOICE

in this important matter. It will not affect old code except that coders will probably want to add MSBSTRINGS into their source to state which one they're using. I would go as far as suggest making LSBSTRINGS Fasm's default mode of operation in the long run. Compatibility is good.

It's just terrible having to write reverse strings when addressing screen with words. Or when managing data, anything in hex will follow normal Intel syntax but when using data as a string it must be reversed. And this is done even worse by not having string concatenation operations.

WE NEED A CHOICE! Fasm is not a standard, unfortunately, and there is a need to comply with the established standards at large. And that is Intel notation.

I think concatenation like this wouldn't be possible without many changes in FASM core. And i haven't yet met with case where it would be really needed.


Acutally, it's reversed in "normal intel syntax". For example look at this in MASM:

in FASM, "1234" always stays for bytes in order as written:

you see, it's "normal intel syntax" where order of bytes is context-dependant, not FASM syntax. This was explained in FASM manual i think. Only place where people usually use strings as value of words and dwords, is when testing part of string. So they end up reversing it manually anyway.

just for yourself, browse over some MASM code you can find, and count how many times are these "string dwords" used in another context.

And yes, it's unstandard. That is way FASM has chosen. To break few standards to create better syntax. In my opinion, it has mostly succeeded.

Or for fun, try to deduce what bytes does thes produce in MASM, without trying it:

so much to clarity of "normal intel syntax" way.

It's not context-dependant but perception-dependant: Intel syntax looks at strings from the CPU register order viewpoint. Fasm looks at them from memory order viewpoint. However the Fasm opinion ignores the fact that not every string is just a constant to be written to display memory for output. And after all it is the CPU we are programming, not the memory.

The basic Intel syntax does not "reverse" anything. Memory data order is an architectural fact and Intel syntax merely conforms to it. mov eax,"ABCD" you can be 100% that eax="ABCD" with Intel syntax. The point is that strings are DATA and not just something output to screen. If you omit this fact of course you can't see why someone would have an issue with Fasm strings. It is a major issue that

mov eax,"1234"
and
mov ebx,31323334h
do NOT result in eax=ebx!!

Again I am not asking for change but for options. If you don't like it fine, don't use it. However please make a slight effort to understand how important standards are and let people have an option of having a standard way of string handling. It's not away from you in any way so stop being so defensive and try to see all the benefits from giving an option to be able to conform to standards.

And if you think a little more you'll probably realize that adding preprocessor functionality is not a major change into Fasm core. Or is "A"."B"="AB" somehow a difficult concept to grasp?

Stop with the negative attitude. Adding functionality and standards is never a bad thing.

Or is Fasm the "my way or highway" assembler?

yes, you got some point in that... both ways have their reason, but for practical use FASM way is still somewhat better


something like that.

FASM tries to keep it's syntax as simple as possible, so i personally don't think some way of "customing" syntax like this would make it into FASM.

May I ask which assembler does NOT demand the user to accept certain limitations?

"1234" is a collection of characters, not an integer, or a collection of integers. I would not expect to encounter 31323334h either in a cpu register, or in DRAM memory, if I were seeking to represent the integer value 1234 in hex. Perhaps it is the concatenation of separate integers which underscores the problem....In any event, I don't find FASM syntax in error, simply because it is non-conformant with Intel, the folks who were unable to follow convention about source and destination.

The following line is handled differently by certain assemblers:

mov ax,'Hi'

NBASM16 00.24.95 -- iH
NBASM32 00.26.04 -- iH
NASM 0.98.39 -- Hi
YASM 0.4.0 -- Hi
FASM 1.67.5 -- Hi
TMA 980705 -- iH
Octasm 0.15 -- Hi
Pass32 2.5.2 -- Hi
LZASM 0.52 -- iH
OpenWatcom 1.5 -- iH
NGASM 1.3 -- iH
A86 4.05 -- iH
WolfWare 2.23 -- Hi
ArrowASM 2.00c -- iH

The best workaround is just to use the hex equivalent: mov ax,4869h

If someone really needs a string dword would'nt this suffice...

Well my main point is simply that why can't we have a CHOICE in this very important matter?

It makes code porting horrible having to reverse strings by hand in source. A single directives pair, MSBSTRINGS and LSBSTRINGS, would solve all the problems. Humans like to do things in differing ways so the best way to solve the problem is to offer the possibility of choice.

Moreover it's somewhat terrible that a data type is destroyed completely, as there is not really such a thing as a memory word/dword string anymore. Do you see that the distinction between db "ABCD" and dd "ABCD" is there for a very good reason? It's a somewhat fundamental change to remove this separation.

Fasm is a great assembler but these unnecessary quirks will probably keep it in the sidelines forever. Not exactly what I'd like after spending years honing the code but hey, I didn't. Some userfriendliness and standardization goes a long way.

A macrosed solution could fit your needs? Overloading every instruction and doing a "if op eqtype ' ' /reverse string" could do the work for you.

I have no time to write this for you but you can check the "assembly listing generator" I did in macroinstruction forum to get an idea of how to overload all of the x86 instructions + assembler instructions like dd, dq...

The negative attitude is yours, Microsoft has a big influence but is not a
standard,there are no standard assembly language.
You are used to do things in the wrong way and now you think it is a standard, and that most assembly language developpers are wrong.

Well, some of us, (ok, just one of us, me,) think that FASM is ALREADY too big and too bulky, offering all manner of options, some of which have little to do with bare bones assembly language programming. Indeed, if one peruses HEAP, the high point of this forum, one will discover numerous applications using FASM, having nothing to do with programming. In any event, there is a price for "flexibility", it is not intuitively obvious that introducing more choice of parameters makes a software product more "user friendly". I am thinking back a few decades to the various implementations of LISP, and COSTAR, to name just a couple of boondoggles which offered users lots of flexibility, but took forever to learn well. For me, the simplest illustration of this scenario, i.e. lots of flexibility versus simplicity of operation, is highlighted by the distinction between vim, and emacs. Vim is simple enough for a debutante to learn in half an hour, while emacs takes a lifetime to master.
I believe most folks share this sentiment, so then the questions which arise are these:
Is fasm sufficiently user friendly? Well, of course not. Like all software products, it needs improvement in that regard. The forum helps to identify areas which need improvement, and to provide an opportunity to discuss some suggested improvements. However, I personally don't think that FASM will be improved by adding yet another pair of options, LSB, MSB for choice of string representation in memory. Should I insist that Tomasz rewrite FASM to conform to my notion of source, followed by destination?
Second question: Is FASM a standard? Sure not. No, TASM or MASM would be the standard, depending on which authority one consults. Most of us on this forum, however, prefer FASM to either TASM or MASM, and the fact that FASM is NOT STANDARD, is, for many of us, an attractive feature. I remember a famous aphorism by Lee Iacocca: "Lead, follow, or get out of the way."
In my opinion, FASM is LEADING, not following, and certainly not in anyone's way.....

funny, vim vs. emacs was exactly the example that came to my mind

try to "read" this then:

should conditional jump opcode names be changed too for "program" (not code) to become readable?

My point is exactly that when we'd have options to describe the behavior it would be 1) self-documenting 2) user-friendly 3) standards-friendly 4) learner-friendly.

And yes, having options to reverse the order of operands would be an excellent addition, as that is one more issue where there are differing conventions. It would not be away from anybody. It would contribute significantly to the flexibility of Fasm. And that is something that users like. This is exactly the kind of stuff that makes software BETTER, not worse. The road to purism is a lonely and forever narrowing path.

Moreover the issue of string representation is not a small one because at its lowest level it's ordered by the hardware. Hardware designed and made by Intel, which is why I'd like to stick to their syntax. We're programming the CPU by hand so I take the viewpoint (similar to Intel) that code should reflect this fact and thus order strings like they will appear in the CPU. It is assembler's exact duty to order strings so that they will be correctly represented in memory. At runtime the hardware will do this same thing for us (mov [eax],"ABCD" will get properly stored into memory). It's very strange that the assembler would contradict this. See my earlier point about Fasm all but eradicating the notions of word/dword memory string. That is not right.

Having to rewrite Fasm based on user requests would be stupid. But I'm not asking for a rewrite, I'm asking for an addition. Adding things is good, especially when they broaden the possible user base and conformity to established conventions and standards. If you like to deny Intel's position as standard just please go first ahead and fab your own chips...not to talk about inventing and commercializing them in the first place.

Fasm could use a ton of new features. Unfortunately the code is so sparsely commented that I'm not willing to spend the time to understand it so well that I'd be able to modify it. Even aspects to porting it are not explained.

Tomasz is obviously an assembly wizard. What I'm trying to make him understand is that it's simply not enough. One must have understanding towards users and their needs, which may vary a lot from the author's needs. The skill to balance these two into a good code which does not suffer from bugs or bloat yet is feature-rich and user-friendly is the real test of how good the actual program is. The "my way is the only right way" is simply a somewhat misplaced attitude here.

BTW, my editor of choice is gVIm Yet I'm happy that Emacs exists for the people who like something like that. I don't see a war of editors here, I see happy and fruitful multitude. Live and let live. That way it'll be better for us all. In the end, it is a positive, giving and understanding attitude that wins the day, and more.

In my opinion, it is a sign of interest in FASM, not "stupidity", on that useful day when someone offers to the forum a suggestion for "improvement".
"flexibility", "choice", and conformance to different "standards" all represent additional bulkiness, and increase, rather than decrease the improbability of comprehending the source code.
I believe Tomasz considers himself an "artist", rather than a "wizard". Both descriptors could be applicable when attempting to decipher his code.
Regarding "standards", I am much less interested in conformance to Intel's notion of anything, and much more impressed by a program's ability to transcend Intel's illogical hardware, with a readable, instead of inscrutable, solution. I continue to hope for a rewrite, or wholly new design, as befits an author working as a computer scientist, rather than as an obscurantist--whether wizard, artist, or sorcerer. The creation I seek is a single speed tricycle, not a Mercedes.

String Concatenation can be solved with the use of the FIND & REPLACE TOOL.

Search > Replace ...
Text to find: " MY_STR_VAR
New text: B"
[REPLACE]

Stop trying to reinvent the wheel.

-------------------------

As for having to reverse strings, make a script to do it, you could write 20 lines of javascript to do this for you on a whole document (possibly a macro right in fasm). Why do we need more directives and clutter.

I'm sorry but that is ridiculous. Think about displaying a "-" in color. What you want to do is

HLITE EQU 20H
mov ax,HLITE."-" ; unix style concat operator and Intel syntax
or
mov ax,"-".HLITE ; Fasm string mutilation syntax, color in LOW byte wtf?

Sure you can hardcode it and use search and replace, for shitty unmanageable terrible to read code. Or make a second table of colors simply for the case of these operations with shifted values, 2000H above, and use the + operator. Which is what I've done this far. So terrible it hurts.


You don't get it do you? YOU DO NOT HAVE TO USE IT. But there are other people in the world! Who are you to dictate what they should want to use?

Most great programs, like my favorite editor, GVim, are done exactly in the fashion that the original functionality is never changed or sacrificed, yet new features are implemented to cater for new needs. A person who learned to use Vi over 20 years ago can still use GVim with the same skillset with zero learning time, while advanced users are offered a wide ranging gamut of scripting and customization options. Now would we have GVim as great as it is if the author had listened to purists and NOT kept on making it better? Luckily he was smarter than that.

The single-mindedness here makes me thing of a cyclop riding a bright red single speed tricycle

LCaseOnlyASM.COM is a program that would be very usefull!
UCaseOnlyASM.COM is a program that would be very usefull!!
TitleOnlyASM.COM is a program that would be very usefull!!!

It's strange, you are asking new fetures to FASM that we are all using, and I am asking for LESS options...

For example, I don't understand why FASM is able to evaluate mathematical expressions like 1+2*3. a VERY GOOD assembler would oblige to calculate inside a comment:

MOV AL , 1+2*3 ==> STUPID, SHOULD BE FORBIDDEN
MOV AL , 7 ; Because 7 = 1+2*3 ==> THIS IS OK

The main reason of my point of view is that each STEP inside an ABSTRACT path leads to nowhere, and is interesting only for stupid people trying and tryingand trying. In the opposite, each step inside a NON-ABSTRACT path leads to NON-ABSTRACT programs, driving NON-ABSTRACT hardware.

What you can reply is : """WHY SOMETHING INSTEAD OF NOTHING ??"""
What you can reply is : """WHY NON-ABSTRACT STUFF INSTEAD OF NOTHING ??"""

Well don't use them. What's with the fascist tweak that wants to prohibit the options from others? So that you can show off how well you're doing without? Pissing contest?

Why are you using Fasm anyway, Real Men code in hex, you sissy!


It's only stupid because you omit commenting why 1+2*3 is there. Much easier to maintain in the future if there's any chance of the values changing. And if the change is upon someone's whim, then we'll have MOV AL,1+2*PISSLENGTH instead. You'd want to hardcode that?

You don't like it, don't use it. Simple as that. But you have no say as to how others want to write their code. You're no better or worse than anyone else.

How's about 'live and let live' instead of 'my way or highway'? Because the latter at no point asks you to give up anything, whereas the former asks for everybody else to give up everything that differs from yours.