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

Actually, as most modern assemblers still enforce this style, it's
hardly obsolete. You might argue with whether this is the most readable
format or not, but you can't call it obsolete.


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

And what are those?


Since the Assembly Rebirth,

When did that occur?
In the past, you've said that the "assembly rebirth" would occur when
people gave up their HLLs and switched to assembly for their
application programming. That certainly hasn't happened yet. Indeed,
you often accuse me of setting the assembly rebirth back a couple of
years; if that were the case, how could it have happened yet?

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.

I guess if you're trying to compete with old BASIC programs, putting
multiple statements on one line is one way to do it. But as few HLL
programmers cram multiple statements per line (as those programmers
tend to find such code unreadable), I don't see how pushing this style
in assembly language is going to convince those HLL programmers to
switch to assembly language.



Therefore, i have developed and proposed a new Assembler,

From the guy who complains about how useless it is to create a new
assembly language when someone else does this...

with
a simplified Syntax,

Define "simplified" Substituting punctuation characters for reserved
words, for example, is hardly a simplification in most people's eyes.


a Macros System powerfull enough to make
the programmation easy,

Well, easier than an assembler without macro facilities. But not as
easy as assemblers that have *truly* powerful macro facilities.

and edition Tools making the developments
fast, secure, and easy, comming with several Writing Style
recommandations.

Okay. But what makes *your* recommendations better than existing
styles?



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.

Where's your proof of this statement?
Increasing the "density" of the source code is not an accepted way of
improving readability. Indeed, most software engineering texts that
have seriously covered this subject recommend appropriate use of white
space to *reduce* the density.

If you know something that all the researchers don't, and you have
proof that this knowledge is true, feel free to share your research
with us.

This is a detail, but, in matter of Writing Style,
each detail has its importance.

Okay. But one important detail software engineering researchers have
discovered over the years is that multiple statements per line is
generally a very bad thing when readability is concerned.


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.

So? What does that have to do with sticking multiple statements per
line?


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

No, they are not isolated. The most basic combination of instructions
is a "sequence". That is, a one-dimensional list of instructions. And
it's only natural to represent a one-dimensional object in
one-dimensional space. By sticking multiple statements per line, you're
trying to force a two-dimensional structure on something that is
inherently one dimensional.


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.

A word has been given to this. It's called a sequence.

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.

No, there is no reason to give each sequence a name. But, as you're
probably about to claim, it is important to denote each sequence in a
readable program. This, however, is not done by placing multiple
statements per line, but by using blank lines to separate such
sequences.


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

Sure, you could. And other than the triviality of that, there's nothing
wrong with this. The real question to ask is "have you made the code
more readable by doing this?" If you zero out lists of registers
frequently, there is a benefit. If not, then it takes more work to look
up the macro than it does to read the three explicit instructions.



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

Except that "mov" *is* a macro here. All you've really done is change
the name from InitToZero to mov and require an extra parameter. Well,
that's not quite correct, you've also violated an important style
guideline and reused a common instruction name (mov) as a user-defined
identifier, which is confusing to most people.


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

That have the same problem.


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

Why should it become this?
Someone quickly reading through the code to find out where AL is being
stored may miss the statement to the right.


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

Sure, it is. But you've failed to prove that this is somehow better.
Function/procedure calls and macros are *abstractions*. They allow
someone to collapse a common operation into a single name, that they
can associate with that operation. There is benefit to such
abstraction. But cramming multiple statements per line hides the
remaining statements on the line (beyond the first) without the benefit
of having a named abstraction. E.g., in your example above, loading ESI
from Pointer does not imply, at all, that you're storing AL into the
location pointed at by Pointer. This is where your analogy breaks down.



This method has several technical advantages:

1) It encreases the density of the Source.

This is not an advantage. You might try studying typography and
graphic arts at one point or another. One thing you'll learn is that
the easiest-to-read material happens at a certain shade of gray
(roughly equivalent to 18% reflection, which is what the human eye is
optimized for, as this is the typical reflectance in nature). Too much
white (too little density) is less readable, too much black (too much
density) is worse. You want to strive for balance. And cramming
multiple statements per line is too dense. Indeed, one statement per
line is generally too dense (that's why we use blank lines to separate
certain sequences in the program).


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,...)

And where is your proof that this is better?
While there is certainly evidence that having *short* procedures (that
fit on one page) makes programs easier to read, I've yet to see any
study that shows that cramming the statements of a large procedure
together, to force it to fit on one page, makes the code more readable.



2) It directly encreases the readability, by reducing the
visibility of the instruction having poor interrest, for
the first sight reading.

Exactly how is "mov D$ESI, AL" of "poor interest" in your previous
example? Again, you're confusing the notion of abstraction, which *is*
a powerful tool for hiding unimportant details with cramming multiple
statements per line. There is nothing in the "mov ESI, D$Pointer"
instruction from your earlier example to clue someone in on the fact
that what is really happening here is "[Pointer] = AL". That's why
your argument fails.


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

If they are not important, then remove them. Then tell us how
unimportant they are. And if they're important enough to belong in the
program, the programmer should be able to easily read them and
understand what's going on. If an abstraction is called for, use an
abstraction (like a procedure or macro). Otherwise, make it easy for
someone to read the code. Hiding instructions behind others does not
make the code easier to read or comprehend.



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

That is does. But it's a poor organization.



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.

This has nothing to do with using multiple statements per line, and
everything to do with the fact that RosAsm programmers (following your
instructions) tend to do a lot of "cut&paste" programming. If you don't
understand why this leads to larger applications, you might want to
think about it for a while.



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.

You seem to be talking about yourself here, except for the part about
quoting books. Truth is, you've *made up* most of these points. They're
just your opinions with no proof or evidence to back them up. Go do the
research and *prove* these points you're making. As it is, your
comments run contrary to everything software engineering has taught us
over the past 40 years. That's not a good sign. Particularly if you
plan on having all those HLL programmers jump in and program in
assembly language when your "assembly rebirth" starts.
Cheers,
Randy Hyde

.

Quantcast