I am experimenting with assembly code formatting.

The idea is to write multiple instructions per line to use horizontal space and decrease code length.

I wrote simple 'emit' macro which let me write code like this (see attached image). This isn't perfect but I find it manageable.

Do you have some suggestions, ideas?

BTW, I don't use any fasm's macros (like invoke) by choice.

Thanks.

It looks very compact and you can easily get a nice big view of it all but I think it will only reverse the problem. The problem with vertical reading is that you can't easily see all the code, but if you reverse that and put everything more in the horizontal direction, you'll easily find the code you need, but you'll strain your eyes searching for what you need in the horizontal direction.

Just be absolutely sure you know what you're doing before you settle with this, if you regret it a year from now it will be boring to convert it back again.

When all gets down to the truth, you can't get rid of your code or reduce it to nothing, I think one has to get used to the fact that code accumulates up and instead of compressing it, I think it would be wiser to keep everything in more manageable include files or other types of modules.

Because in the end, you can't really get rid of your own code, it gets large, and it's ugly, but one ultimately have to get used to it by manageing it better.

Finding a way to organize code is one of the hardest things in the world, but having very large chunks of code in the vertical direction is actually very useful because not only does it obfuscate code, it also "snipes in" on small chunks of code you want to focus on, it has disadvantages and advantages.

Just trust that, because there is no time that you want to keep all your code in your head anyway, if you find that you need to "think" about your code in a manageable way, you'll probably want to create compartments in your thoughts:

Practice your mind to only focus on the code you need to focus on, and eliminate everything else. If you can do that, you will not need to compress your code. Learn to eliminate everything else and keep total focus on the code you need to work on at the moment, just flat out throw it out of your head, as if it didn't exist.

People who think about managing their code better are very experienced programmers, so you are obviously an experienced programmer. Usually, programmers who seek to manage their code better are also dependent on perfection when it comes to code, based on this I can tell that you are a perfectionist.

This is what I want to bring up to you, try not to be a perfectionist, go back a few years when you were a more inexperienced programmer when you tried and failed more rather than trying to get everything perfect right away.

Don't be afraid to do mistakes. Perfectionism in programming will put serious handicap on your learning curve.

Thanks for your insights. I have decided not to code like this. I will format my code vertically.

Yes, I like to get everything perfect right away and I don't like to fail. I am aware that this attitude isnt't always good.

Some lines are OK to go together, but then it seems like invoke.
Some don't look good at all (e.g. all of those mov's).

My favourite one line macro

Change Z for any condition.

invoke (or any other fasm's macro) is not an option because I don't use any standard fasm's header.

Macros are most useful if you change the big parameters for your programs very often. But if you have a very strong system at the core, macros are not really as powerful as it could be for someone who change his source often. It has to be weighted up to the need of the coder.

In the end, macros have no value, it's just 'nothingness' that helps create a more dynamic source generation. Beyond that it's an empty concept and if you find that you seldom need to change the source, there is no need for complex macro's.

Don't be misled by the incredible vastness of complex macros that the forum relies on. They've spent years creating these macros, in the same amount of time, other people have spent years creating entire applications. Time-based, the people who favors macros have spent years creating nothing, and the other group have created something.

There is a difference and you should only create complex macro systems if you're irrational and want to waste huge amount of time for nothing. If you get 'bitten' by macros, they are very addictive, you'll probably spend the rest of your life doing macros, and by the time you retire you don't know why you did them.

If there is no default macros that work incredibly good enough to be utilized for complex usage, the time you need to create them manually is simply too great to be worthwhile, because it builds up, when one macro is accomplished, you want to create another one, and another one and another one, until you're doing nothing but creating entire libraries of macros. If the author of the assembler haven't provided enough macros to use it for complex use at the first moment, there is no need to bother with macros. Focus on the program you want to create.

If I were Tomasz, I would create two modes of macro operation. One mode is for simple use and other for complex use so that one type of user can use the predefined macros without compatibility issues, and the other can set the assembler into complex mode, if he need to customize the assembler/preprocessor.

Perhaps just a simple statement at the top of the source like this:

MACROSYSTEM 'Simple'
MACROSYSTEM 'Complex'

or something similar. While in the simple mode, the author of the assembler can break "any" rule he feel like breaking without worry of disappointing the complex macro users. This allows the assembler to "form" very strong standards, which makes an extremely good assembler for the productive kind of coder.