Re: RosAsm?
From: C (blackmarlin_at_asean-mail.com)
Date: 04/08/04
- Next message: C: "Re: RosAsm?"
- Previous message: BSpider: "Automatic sector relocation on modern hdd"
- In reply to: Betov: "Re: RosAsm?"
- Next in thread: The Wannabee: "Re: RosAsm?"
- Reply: The Wannabee: "Re: RosAsm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 8 Apr 2004 07:22:24 -0700
Betov <betov@free.fr> wrote in message news:<XnF94C4126246CBCbetovfreefr@212.27.42.72>...
> "wolfgang kern" <nowhere@nevernet.at> crivait news:c4v4ac$2h2$1
> @newsreader1.utanet.at:
Has someone changed our Betov for a new one? This is the
most astute, well thought out and correct post I have seen
from him in a long time. As a result I will add my voice
in support of his points.
> >[...]
> >
> > OK. Even I prefer to write:
> >
> > push 1D012h ;MB error: "end/retry/ignore"
> >
> > rather than:
> >
> > push &MB_ABORTRETRYIGNORE___&MB_SYSTEMMODAL___&MB_SETFOREGROUND__
> > _&MB_TOPMOST___&MB_RIGHT___&MB_ICONHAND
>
> Well,.. you will do it the way you like ;) , but, again,
> the problem is with _readability_: Readability have, for
> example, effects on maintainance. Not only, when another
> reader will see "1D012h", he will have no cue on whatever
> that value could be, but, worse, the day _you_ will want
> to modify some of the Flags, you will have to completely
> re-analyse the components of "1D012h" and to "recompute",
> by hand, your new value after having re-read the Doc...
Yes, and furthermore, if you write code like I do, internal
communication values such as these can change freuqently
before the final release -- having to modify dozens of
numbers is both tedious and error prone.
> How much time will it cost you the day you will mean to
> replace "MB_ICONHAND" by "MB_ICONQUESTION"?...
Exactly (similar to my above point)
> Also, things like "MB_ICONHAND", "MB_YESNO", and so on,
> are very easy to memorize, whereas the real value are not
> easy to remember.
That depends on the person, though they are more readable,
ie. where I could guess at what MB_YESNO means I would have
no idea of the utility of its numerical equivalent.
> All of this discussion may seem a matter of ridicoulous
> and not important details, but, in fact, this is _very_
> important: If Assembly is almost dead, as an Application
> Programming Language, this, is, partialy, because of this
> old fashion style you are actualy prefering. A very real
> fact is that plain traditional Assembly writing style _is_
> more difficult to write and to maintain than HLL.
Yes. In a related issue, I use macro 'pseudo operators'
to also increase code readability. Therefore in my code
you see "clr eax" instead of "xor eax, eax". Excatly the
same code is generated, though I believe the former is
easier to understand.
> Assembly _can_ compete with the HLLs, if we redefine the
> way for writing from scratch. Another example is with the
> traditional Mono-Instructions Lines:
>
> There is
> absolutely
> no reason
> to write
> like this
Well, if you elide the indenting this is often a real pain
to read as there is not clues to the code flow. And some
constructs (eg. function dispatchers) just read better when
you are able to write multiple instruction per line. For
example...
cmp al, 6 \\ je function_for_6
cmp al, 23 \\ je function_for_23
cmp al, 42 \\ je function_for_42
jmp nasty_error_message
> Same with Comments put at the end of line. There is no reason
> to comment Instructions.
YES!!! There is nothing more annoying to the experienced
assembler coder than reading code where some idiot has
typed (or the equivalent) for every line of code...
inc eax ; increment eax
Not only does it fail to give any information above what is
already stated by the code itself, but it also adds unnecessary
visual noise and wastes the programmers time; time which we
all agree should be spend bickering in alt.lang.asm :-)
> We should comment what the program
> is doing, not what the instructions are. Not only the old
> fashion manner is absurd, but, worse: It is a true hell to
> maintain: When you want to delete, modify, insert, instruction
> you kill your comments at the same time, and it become a
> vaste of time to reoganise the comments (what does never
> happend with independant Comments-Lines discribing a coherent
> set of Instructions).
Yes, and with a good selection of macros and enumerations, code
can be written to be virtually self commenting, therefore a
comment is needed only every dozen or so lines along with the
occasional review of what the registers are doing for complicated
sections along with notes on what functions do and algorithmic
descriptions of particularly nifty optimisations. A good example
would be some thing like ...
pnt: ; print a string (DOS / NASM)
; ds:si := string / asciiz
; assume df := fwd
push si
lodsb ; preload (assume 1st is not 0)
mov ah, BIOS_VIDEO_WRITE_TT
.0: int BIOS_VIDEO
lodsb
test al, al
jnz .0
pop si
ret
With a good set of macros this can be made even clearer...
; print a string
; in: DS:SI->string/asciiz
; assume DF := fwd
procedure pnt
use si
lodsb ; assume 1st is not 0
mov ah, BIOS_VIDEO_WRITE_TT
do
int BIOS_VIDEO
lodsb
loop_until al, equal, 0
end_procedure
(NASM can compile this, producing exactly the same code as
above, given suitable macros).
> A good Asm Source should be readable, at least at a formal
> point of view, by a beginner just having learned the basics
> of the Mnemonics. That is, is should, simply said, be written
> and organised as close as possible to what any human text
> looks like. This imply to take some 'distance' from plain
> true Assembly. This 'distance' must be, and can be, under
> control. I mean, for example, with an HLL Pre-Parser, like
> the HLA horror, this distance becomes a serious problem
> because the implied abstractions levels achieve in making
> the Assembly simplicity and reality impossible to read and
> to understand. This is why, in my previous post i was talking
> of _ONE_ abstraction layer. As long as you keep with _ONE_
> abstraction layer (or as Beth prefered to say: One simple and
> direct _replacement_), there is, IMO, no problem at all:
Yes, in this vain in my option the only programmers who should be
using macros are either beginners or experts. The former because
macros (providing they are well written) make assembly much
easier to learn and the latter (as experts know exactly how the
macros works and what it will produce) to save time and make the
code more readable. Only intermediate programmers should avoid
macros while they get the feel of the assembly paradigm.
> Assembly is yet there, even if 'TRUE' is not as plain concrete
> as "1". After all, 090h is also more 'concrete' than NOP, but
> who would prefer writing the number, instead of the Mnemonic?
> What for?
Exactly, and the number could have other meanings, while the
mneumonic has a fixed meaning. Therefore, while the number is
more concrete (ie. less abstract), the mneumonic is far more
readable.
> You seem to be difficult to convince, and i well understand
> that changing the point of view is a real effort for an old
> timer, but, please, think of it again. Assembly may have a
> real futur, and it is now 100% evident to me that this
> possible future is, in no case, with a writing style prefering
> "push 1D012h" to the verbose, Auto-Commented, version... ;)
I think you have hit on the main point there -- self commenting
code. Ie. code which can be read without the need for comments.
And because comments can become outdated or can be misleading
due to typos or changes, self commenting code is preferable
(though not always attainable.) To return to your example,
yes, "push 1D012h" easier to type, but it is difficult to under
-stand without the comment -- say, however, if we typed "push
1D021h" by accedent -- the comment would now not help but hinder.
On the other hand, if we typed,
push MB_ABORTRETRYIGNORE | MB_SYSTEMMODEL \
| MB_SETFOREGROUND | MB_TOPMOST | MB_RIGHT \
| MB_ICONHAND
Not only do we not need comments, but a mistake becomes much
more readily noticable (a simple typo would be probably caught
by the assembler in a "Label not defined" error and probably
would be noticed by the programmer before the compile.)
(If this construct is used often it could be written in a macro
or a new enumeration created to save typing.)
Of course, one may argue that in this case it is not to
important as any error would be quickly detected, but this is
not the case, say in the middle of some central engine where
the output would not occur for thousands, maybe millions, of
instructions hence possibly building up other errors until the
original cause is completly obscured.
By using enumerations such logical errors become much more
unlikly to be made and, as a logical error cannot normally be
detected by the tools used to compile the code, any reduction
in the number of these errors will save much time in debugging.
C
2004-04-08
- Next message: C: "Re: RosAsm?"
- Previous message: BSpider: "Automatic sector relocation on modern hdd"
- In reply to: Betov: "Re: RosAsm?"
- Next in thread: The Wannabee: "Re: RosAsm?"
- Reply: The Wannabee: "Re: RosAsm?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
