Another update follows closely, as I found a way to add another experimental ability to CALM's MATCH. I realized that in context of CALM modifying a wildcard with "?" is not really needed (because the identifiers in CALM are seen as uses, not definitions - only declarations of parameters and LOCAL statements are definition-like) and I had just a perfect feature that could use this syntax space - a wildcard marked this way can be matched with an empty text. This widens the gap between regular directive and more-capable command available to CALM, but the regular directive has only so little syntax design space available. And places where these features are most useful, should be better off using CALM anyway: Please keep in mind that any features that I add to MATCH need to respect the original design (which was first made for fasm 1). It based on an assumption that it should be possible to implement it in a way that would not allow for a potentially catastrophic backtracking. This is why every wildcard is said to match as little text as possible (so an optional wildcard is going to try to match empty text whenever possible), why literals cannot be optional, and why bracket checking option disallowed presence of the same brackets characters in the pattern. Such design allows matching to be performed with no real backtracking. The limitations require sometimes multiple MATCH commands to be used, but I believe this is still better than to have MATCH that might catastrophically backtrack.

One more little feature added: TRANSFORM can now take a second argument to identify and replace symbols from a specific namespace. This simplifies a trick I've been using to recognize size operators in x86 instructions (although performance gain there is negligible), but I believe it can be even more useful in other places, while it required almost no effort to implement (because it uses an option that fasmg engine had anyway). Note that the namespace base is resolved at compilation time.

I think the language of CALM is mostly complete, though. One thing that I considered but did not make it into language is a way to call another CALM instruction directly (without having to pass through ASSEMBLE). I may revisit the idea further in the future, but so far I did not see enough advantage in having it.

Hello. After some time, I've just encounter a problem in my project.
It's just a little question . In this code:

A it's expanded to $00. So everything work fine but with the initsym in place of arrange the result is different.

I don't understand why the symbolic variable "A" is defined in the scope of "nested" CALM and not in the "test" CALM.
I really sorry if this was answered somewhere.
PS: I don't known if it's a normal behavior but you can define stuff like that:

space can be replaced by dot?
Thx in advance.

It is related to something I have written a few posts backs: The ARRANGE command does not add context information to the symbols it copies literally from pattern, and then it see no defined value associated with symbol, it just treats it as literal. So "A" in the "buffer" has no context associated with it when you prepared it with ARRANGE, and so the current context is used at the point when what command is executed. It would be safer to write "arrange buffer, initsym =A, $00" there instead, as then it does not depend whether there is some "A" symbol defined that ARRANGE could use for value replacement. The way you used it there without "=" is actually a fallback mechanism, that could even be made to show an error message.

When you instead use INITSYM, it gets called like a macro, so the values of arguments carry their original context - in this case the context of "nested" instruction, because that's where the INITSYM has been called. This text of argument is then assigned as-is to the variable, and the command you get in "buffer" ends up having a different context for "A".

Also, in both cases the command you execute from buffer is another INITSYM, which then again adds context to the text that did not have one already. So in the first case, when "A" in "buffer" had no context associated yet, in becomes equipped with the context of "test", while in the second case it already had the context of "nested" and packing it into another one changes nothing.

In practice, in many cases this carrying of recognition context works so naturally that you don't really notice it. But with ARRANGE you should remember that the context is stripped from the symbols in the pattern. Although I could make it so that when name is not preceded by "=" but no value is found for that symbol, it could be copied as a name with additional context, but this would not be reliable. I'm still considering adding an error message, though.

These are all valid modifiers, each with specific function, as defined in section 2 of the manual. A final "." appended to the identifier ("place?.") and a starting "?" character ("?.holder?") are two different modifiers. The appended dot allows to re-define a symbol visible in current scope (which may be a symbol from some external namespace) instead of defining a new local one. The question mark at the start of identifier can enforce it being a label-like symbol, for example when the name is numeric. And the ":" that separates the two identifiers is a modifier for macro/instruction definitions that means defining a recursive instruction.

Ok thx you Thomasz.

Yes, I'm sorry. At the time of reading, I didn't understand the original "meaning".

In fact, I said this because with macro in place calminstruction, this not work. I didn't know that a dot can follow a question mark.

In case of macros, the arguments need to be preprocessed parameters, so they cannot use sub-namespaces, etc. Here the arguments are just symbolic variables, and you can use dot operator in their identifiers. The same goes for LOCAL (as opposed to macro's LOCAL, which has to use simple parameter names).

BTW, if I add an error message for ARRANGE when it does not find a defined symbol, would it break much for you? I tried it and I see that it helps to catch bugs in instructions. In fact, it showed me several mistakes in x86 headers, and now I'm convinced I should make it more strict this way.

Yes, why not. This might be more "user-friendly", I guess .

Initially I thought it could be nice to release CALM officially once the version string reaches "it...", to have a clear-cut boundary. Then I changed my mind and released it early (encouraged by all of you that started using it immediately!). But perhaps a final, stable release is going to be "it..." after all.

It is all about having flexibul soolutions. When you construct something, it's about reusing what you already have and add to it, if you imagine a christmas tree and as you put up the tree and add gadgets to it, it should come to a point where the whole tree becomes flexibul enough to be used even if nothing on the tree is really constant and hardwired, everything is built on layers, and that is what flexibul soolutions is all about. It's a little bit like Microsoft C#, everything is built in layers and inside boxes, in a flexibul way.

The oven is the baker's best tool. It makes the pastry firm and unchanging. What is unchangeable becomes sacred over time. What is sacred becomes loved. What is loved becomes a super effective tool.

If you use the christmas tree construction model, nothing becomes sacred, nothing becomes loved, and everybody hates it.

When you need to explain something to people, the art of communication begins at the shortest possible description. If you can't describe your idea in 10 words, you should not be describing it at all. In there lays the art.

The first line should be a 10 word description of your idea that describes your idea, the second line and after that is the full description.

A good assembler respects the time frame that the programmer has at his disposal. He does not have time to play around with a decade long experiment.

Microsoft only seems to be playing around with layers upon layers, they really toss the whole code in the garbage every time and they start over, it's just that it happens so fast you barely notice that.

A good assembler must not build on layers, it should be rewritten, toss parts you don't need, toss parts that needs to change.

Put the project in a loop, it needs to go back to the thinking bench again, rethink, change it, toss parts, rebuild it, until it becomes perfected. Sometimes you need to toss the whole code.

People wants an assembler that has been as many times as possible inside the oven. The assembler needs to be baked in the oven, often, many times, the more often the better. Forget the christmas tree design where everything is in layers hanging loosely on the tree.

If you learn from this then the assembler will succeed, if you continue with the christmas tree design, it will die.

Assembly must not be overcomplicated more than it already is, we have C# for that complexity, asm should not go there. Asm is an art, it's not a "save humanity" project.

fasm needs more non-macro keywords. You need to bake the assembler in the oven and create something unchanging. Macros change, we need more keywords that are not macros, but built into the assembler, like the keywords you find in nasm.

DO THAT, and you will succeed!

How do you do that you may ask, you look for common functionality that all coders need and use on a daily basis, and then you take that away from macros and build it into the assembler. Repeat until all basic needs are hardened inside the assembler.

When the coder has to use macros to function at all, then they will hate the macros. When you build the basic needs into the assembler itself and people don't really need the macros, it's exactly at that point the macros will be loved and become useful.

Success in the horizon, I believe in you.

Favorite baking eventually leads to excess weight and makes you give up on it. And in the oven, the vegetables become tender and slimy. Thus, the oven is also a very flexible tool. em. 4 words, aren't? A typically American approach. Let's try all the wrong options before we find the right one. Although every year they get worsee and worseee. So why keep a dozen different assemblers for a bunch of small microcontrollers. And so it's easier to fix errors and use them as needed. You don't even need to go far for an example.