flat assembler
Message board for the users of flat assembler.

Index > Main > [fasmg] eating the bullet: going full calm

Author
Thread Post new topic Reply to topic
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
If the calm language can provide isofunctionality to the really important classic macro language features (at the price of writting more code) then, for the sake of "ultimate" consistency (since the calm language is a "macro" assembly-like language), why not eat the bullet: port fasmg "std lib" to calm and drop the classic macro language.

The "price" seems to be that for a calm instruction, it is not that straight forward to understand what assembly code is generated compared to its equivalent classic macro instruction.
Post 21 Sep 2021, 17:01
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3307
Location: vpcmipstrm
bitRAKE
I wonder if there are constructions which are more intuitive in the standard macro language without much benefit in calm implementation? Or maybe it is desirable to have both a brief scripting language like the classic macro language as well as a more verbose, fine grain language like calm?

This is probably just my classic macro bias talking though.

_________________
¯\(°_o)/¯ unlicense.org
Post 22 Sep 2021, 00:49
View user's profile Send private message Visit poster's website Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
"Removing" the classic macro language could bring serious cleanup and simplification to fasmg code structure and "specs". And as you said, since we already write assembly, our eye will be already trained to read calm macros.
But, I presume calm can do most if not all of 'classic macro'... and I may be very wrong for obvious reasons I am not seeing right now.
Post 23 Sep 2021, 01:37
View user's profile Send private message Reply with quote
nasm



Joined: 02 Nov 2021
Posts: 35
nasm
I would calm down with any language that is not assembly because creating new languages is a hobby and it's something fun from the author's point of view, unless you are ready to switch to a new language in a year and a half, you should stay calm and wait.

The author has not planned for calm, it came instinctively. And it's this instinct that you should be cautious with because it will force you to switch to a new language in about a year and a half from now.

If calm came about from an old plan that was written down in a rusty old document, I would try calm, but because it came out of the toilet on a random sunday, I suggest you will wait.

You know, it's not very wise to learn a new language every year and a half. He is an innovator at heart and he loves what he do, if you love something, you don't want to say "This is good enough". He will of course continue and create something even better the next time and the question remains whether or not calm will be compatible with that, time will tell.

What I DO know for sure is that I think he is moving forward too fast, I think he should seriously sit down a saturday night or choose which day you want, and really try to come up with something that can make assembly more peaceful and interesting. We need more non-macro keywords.

Forget the "Every idea must come out RIGHT NOW so everybody can read it" scenario.

People have unique opportunities to make assembly something, but time is short, one should not waste time in doing it the wrong way. This requires INTENSE focus and every nerve cell in the body must be on alert on this quest.
Post 13 Nov 2021, 15:35
View user's profile Send private message Reply with quote
bitRAKE



Joined: 21 Jul 2003
Posts: 3307
Location: vpcmipstrm
bitRAKE
Intense focus is not enough, imho. Some things can only be learned in the process - race a few laps around the track to get some data. This is especially true with complexity - so many interdependent parts - language features that work with other language features, etc. Using the language intentionally leads one to an understanding that it was not so carelessly thrown together as you suggest.

The whole "forcing to switch" attitude doesn't seem valid. Tomasz has even demonstrated ways to migrate between different forms of assembly - both from a language specific perspective and systems perspective. It would be an understatement to say he's a very talented programmer.

It's not unusual for assembly programmers to want different language features - that's why macros exist. What non-macro keyword do you need?

_________________
¯\(°_o)/¯ unlicense.org
Post 13 Nov 2021, 16:22
View user's profile Send private message Visit poster's website Reply with quote
nasm



Joined: 02 Nov 2021
Posts: 35
nasm
I'm for innovations that remove things and reduces complexity.

Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away. - Antoine de Saint-Exupery

Hardcoded keywords in the assembler takes away a ten word macro and in return it gives you a one word keyword.

Keywords are the luxury of assembly, don't forget them. Don't be ruled by them, but neither should you forget about them.

If you build your house on sand, you risk the whole house collapsing. Instead, build it on a mountain, unless you have a digger and (modern) sement. Very Happy

Every idea must be processed intensely before it makes it to the panel of judges, or else it ends up being discouraged with criticism and everything rots.
Post 13 Nov 2021, 16:55
View user's profile Send private message Reply with quote
sylware



Joined: 23 Oct 2020
Posts: 81
Location: Marseille/France
sylware
I still don't know enough about CALM to "see" if it provides iso functionality to classic macros.
I have not tried to rewrite the classic macros from my current project using CALM, but I don't think it will be pertinent in giving me more perspective since those macros are really simple.
If you are building experience on CALM coding, it would be very valuable to have feedback here.
Like I was lurking on ELF TLS support (and got scared away by its broken design), I am lurking on ELF dynamic executable support (PIE), that without the usage of an external linker... and such support would have to be written using CALM, I guess.

---- edit

There is also the 'going full case sensitive', that would remove as a whole the case sensitive/insensitive logic from fasmg 'specs', which could lighten to some extend fasmg implementation.
Post 20 Nov 2021, 21:15
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar. Also on GitHub, YouTube, Twitter.

Website powered by rwasa.