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 movement 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.


Visually it takes me longer to see that. Even in a HLL
I would separate the statements,

esi = 0;
al = m[esi];

Also if you block your example there is more within
the areas of the fovea to see without eye movement
or at least minimal eye movement. You can move the
eye down the page without the need to swing it all
the way back to the beginning of the next line
which I personally find tiring.


+-------------------+
| mov esi D@Pointer |
| mov al B$esi |
+-------------------+

+----------------------------------+
| mov esi D@Pointer | mov al B$ese |
+----------------------------------+

This is even more obvious with three statements.

+-------------------+
| |
| (eye) |
| |
+-------------------+

+----------------------------------------------------+
| (eye) |
+----------------------------------------------------+

I even find it useful to break HLL statement,

invoke MessageBox, NULL, \
addr MsgBoxText, \
addr MsgBoxCaption, \
MB_OK

Although perhaps not required in the above example it
can be useful *while learning* so as to comment each
argument used and maybe even take time to show what
other values could have been used eg, instead of MB_OK,
in a *tutorial situation*.




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,


But much of the above assessment comes with practice.

With practice you can visually block a sequence of
assembler instructions as having one function.

While learning assembler every step is of interest.

For example when first learning assembler after using BASIC
I used my knowledge of BASIC to lever my understanding of
assembler instructions.

; BASIC VERSION
ClearLoop:
mov [ed:di],ax ; ax = Memory(di)
inc di ; di = di + 2
inc di
dec cx ; cx = cx - 1
cmp cx, 0 ; IF cx <> 0 THEN
jnz ClearLoop : GOTO ClearLoop

And I found the 8086 had its own HLL instructions so
I used my knowledge of the simpler ones to lever my
knowledge of what they meant,


ClearLoop:
stosw ;mov [es:di],ax: inc di: inc di
loop ClearLoop ;dec cx:cmp cx,0: jnz ClearLoop


As you can see the comments are multistatements which
I guess you would approve of :)

Now I will agree that a single line in this case is readable,

ClearLoop: stosw | loop ClearLoop


You need to be able to unroll HLL statements even if
you always use them. Otherwise you have no more
understanding of what is happening, or the ability
to cross translate to another assembler than a HLL
programmer would understand how the PRINT statement
in BASIC was translated in machine code required by
the CPU.

That is why I found the TDTuts so useful, thanks for
pointing them out six months ago when I first had a
bash at learning Windows assembler programming.
MaybeI will stick it out this time :-)




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 >

.