Re: Multi-Statements Lines

Betov wrote:
Given the noise around this subject, i have to point, again, to
the technical points in favour of this element, in a programming
Style.

One of the multiple problems that have made Assembly a dead
language, along the past twenty years, was that, at a formal
point of view, the traditional Asm Style, was not viable for
developing significative Applications. This obsolete style is
well known:

Label: Statement ; Comment /CRLF

[Including 4 (!!!...) very bad practices at a time...]

Since the Assembly Rebirth, which final target has always been
to enable the programmers with writing real life Applications
(this mouvement started for Win32), in full Assembly, it was
evidently necessary to review the Asm Writing Style, and to push
it to a state where it could seriously compete with the most in
use HLLs, on the front lines of readability and maintainance,
among other things.

Therefore, i have developed and proposed a new Assembler, with
a simplified Syntax, a Macros System powerfull enough to make
the programmation easy, and edition Tools making the developments
fast, secure, and easy, comming with several Writing Style
recommandations.

Among these recommandation, the Multi-Statements Lines propositions
is an important point, increasing significatively the density of
a Source, which, when applied the accurate way, increases the
readability. This is a detail, but, in matter of Writing Style,
each detail has its importance.

The technical logic behind this recommandation is that, as opposed
to the linearity of the old fashion standard style, a Source is
not a linear thing. The evident reason why we have Routines,
Procedures, Macros, and other such organizations.

The very first level of the organization of any Source, is that
Instructions are not isolated things, like words in a Dictionary:

Instructions, like words, in a Text, tend to create some
'sentences', having some 'meaning', that we even could give a name
to, if it was worthy the effort. Nothing but what we do when naming
any Routine... but with consideration to the fact that, under some
quantity of Instructions (let's say around 2 or 5...), it would be
rather absurd to create as many Sub-Routines.

Example: At the beginning of many Routines, you may have to init
some Registers to zero, before executing some computation:

mov eax 0
mov ecx 0
mov ebx 0

... which instructions you could as well replace with a Macro
saying:

InitToZero eax, ecx, ebx

... if it was not absurd to hide trivial MOVs under a Macro,
instead of implementing a general principle of "Multi-Instructions"
Macros.:

[mov | mov #1 #2 | #+1]

... enabling writing, directly:

mov eax 0, ecx 0, ebx 0

... and same for the most used Instructions which may take some
benefit from this possibility (PUSH / POP /...).

One step futher, a Routine may require other Intitializations
than trivial zeroed Registers. Example, intializing a Pointer
to some Variable on the Stack and reading a first Byte, before
some conditional parsing Loop:

mov esi D@Pointer
mov al B§esi

... which should become:

mov esi D@Pointer | mov al B§esi

... which the real form of Multi-Statements Lines.


This method has several technical advantages:

1) It encreases the density of the Source. Therefore, more of
the Source is visible, in one sight, on a single Page,
enabling the reader with a better overview of the overall
organization and other structurations of the Source logic
(Indentations, HLLisms Constructs, Blank Lines,...)

2) It directly encreases the readability, by reducing the
visibility of the instruction having poor interrest, for
the first sight reading. That is, all Instructions of a given
Source, do _NOT_ have the same importance. Some are very important
some are lesser important - for the understanding of what a
Routine may do -.

3) It introduces (this is the most important point), one another
level (the lowest one) of organization in a Source.


The effective results of this detail (concuring, with many other
more important points), is that, whereas the most often encouted
Sizes of the effective Applications written in full Assembly, is,
for the best competitor of RosAsm (FASM) is around 100Kb, the most
typical RosAsm Applications are around 300Kb.


Now, dispiting the insane noise of uncompetent ass-holes, who
have nothing to say but to point to "Book Writers" BlaBla, on
a News Group that is supposed to address Assembly Programmers,
no counter-argument has been given against these technical
points, and the only reaction was, as usual, with having master
Pdf, the illustrious swindler, liar and thief, trying to overflow
the subject with tons and tons of bullshits, up to some point
where the readers would not even recall of my previous posts.
Therefore the necessity of this second shot.,. and not taking
much care of preaching the desert.

:(

Betov.

< http://rosasm.org >




I agree that some instructions can benefit from "repeats". However, others just make the source harder to read and lend themselves to errors that can be more difficult to track down. In Jeremy Gordon's GoAsm, you can do the following

inc eax,edx,ecx
dec eax,edx,ecx
push eax,edx
pop edx,eax

Though I would never use them they are very succinct and not open to misinterpretation. Most multi-statement lines in source do nothing at all to make code clearer, in fact they tend to accomplish exactly the opposite by breaking up the natural way in which you trace program flow. Also when dealing specifically with assembler, it further separates the source from the disassembled code, making it even more difficult to debug nasty problems. Though the separation from disassembled code is not very severe in the case of multi-statement lines, certainly not as severe as the high level constructs such as .IF/.ENDIF etc, it does this none the less.

Why spend time or energy obfuscating source code, nice clean single instruction per line code is a pleasure to read and snap to follow. This is also the reason that I rarely use macros, they only serve to obfuscate code except where they are intrinsic to the assembler, then everyone has the same library of macros and their functionality is well documented.

Some good points in the article and though I use a simple linear coding style, that is just my personal preference, I can't say either way which is better for beginners.

In the end I assume that RosAsm allows you to code in either way so it has all the bases covered and the user, not the assembler author, gets to make the choice.

Donkey
.

Quantcast