Macro Power
rand...@earthlink.net
Rene constantly brags about how "powerful" the
macros in RosAsm are. The real question is
"powerful compared to what?" There is no question
that RosAsm's macro facilities are far more
powerful than those found in assemblers that don't
support macros. But if we compare RosAsm's macro
facilities against commercial-quality assembly
languages (e.g., MASM, TASM, and HLA, or even
FASM) we find that Rene's idea of power is
a bit underwhelming. The purpose of this article
is to prove that RosAsm's macro facilities are
less powerful than MASM's (and TASM's) and
HLA's. I will leave it as an exercise to the
reader to prove this for FASM and NASM (and
you'll find these results to be true as well).
First, what do we mean by "power"? From my
point of view "macro power" means *capability*.
If you can do something with one macro processor
that cannot be done with another, then that
first macro processor is "more powerful" (at
least with respect to that item) than the
second. Note that "macro power" doesn't
mean that everything you can do with one
assembler can be done by a more powerful
assembler. Some assemblers have features that
others don't, and the other assemblers may
have features that the "some assemblers" do
not. To determine which macro processor is
"more powerful" than the other, you have to
add up all the unique features and rank them,
then compare the final scores. This can be
quite complex. Fortunately, showing that
RosAsm is less powerful than MASM or HLA
is fairly easy because RosAsm's feature set
is a proper subset of these other assemblers'
feature sets.
Note that "power" does not include syntactical
issues, only capability. One assembler may
allow you to do something by typing fewer
characters than another. I do not consider
this a measure of power (indeed, in RosAsm's
case the terseness results in some *very*
difficult to read code). Power simply means
"can I accomplish the same thing." The
fact that it may take 5 RosAsm statements
to do the same thing as one MASM statement
is irrelevant -- if RosAsm is capable of
doing the same thing, it has equal power.
BTW, to show that one macro processor is "more
powerful" than a second macro processor, we have
to show that you can simulate anything the second
assembler does with the first, and you also have
to show that you can do at least *one* more thing
than the second one does.
The source of the information is this article is
the "B_U_ASM" manual supplied with RosAsm,
the MASM Programmers Reference, and the
HLA reference manual. So let's get started
comparing the power of these assemblers.
One of the first differences between RosAsm's
macro facilities and MASM/HLA's is found in
the following paragraph in "B_U_ASM" (BUA)
(what does that stand for?
"Butt Ugly Assembly"? :-))
"The Macros engine also offers a replacement
functionality, like the Equates Engine, but,
whereas the Equates can be applied to any member
of an Instruction, the Macros apply only on the
first element of a Statement, and, whereas, the
Equates are 'one word only' Macros can have
Parameters, and can produce complex
multi-Statements outputs. Also, a Macro can be
applied to the first component of a Statement ."
Basically, what this is saying is that RosAsm
only allows you to replace the first word
(typically the instruction mnemonic) of an
assembly language statement. Neither MASM nor HLA
has this restriction. With those assemblers, you
can specify a macro *anywhere* within a statement
and the assembler will handle it properly. Right
off the bat, RosAsm is falling behind. RosAsm
provides an ugly "paramacros" syntax to try and
overcome this problem, but paramacros "apply to
the parameters of a statement" and don't appear
to be generally usable (that is, you can't expand
them anywhere). RosAsm's paramacros also require
a different syntax than standard macros, further
confusing things.
RosAsm uses a very terse symbolic language to
refer to macro parameters and other objects. This
yields nearly unreadable macro code and will be
especially difficult for those who've learned
other macro systems to follow. Here's the main
things from BUA:
-------------------------------------------
(# stands for 'parameter number')
#1 means 'moveable first parameter' (1 to 9, but 9 is not true
last limit).
#F means 'fixed first parameter'.
#L means 'fixed last parameter'.
#n means 'movable last parameter' (for direct backward unfolding).
#+1 means 'loop from start and add 1 to all parameters numbers'
(not to F nor L).
#-2 means 'loop from start and sub 2 to all parameters numbers'.
#5>8 means 'copy parameter 5, 6, 7, 8' (always '>'
never '<' here).
#L>2 means 'copy parameters from Last to second one' (always '>'
never '<' here).
#x means 'loop number'.
#=5 means 'Evocation must have 5 Parameters, if not, send me an error
message'.
#1! means Same as #1, but strip last Character (to build symbols
from Labels).
&1= means 'store what follows in internal Macro Parser Var1'.
&2 means 'replace with internal Macro Parser Var2'.
&0: means 'I want an Automatic Label here'
&0 means 'replace this by last declared Automatic Label
evocation'
NOPE means 'do nothing here' (Dummy Macros. In fact Dummy
Mnemonic: NOPE).
----------------------------------------------
Catch all that? Well, if you didn't, here are
some sample macros that appear in most RosAsm
apps that should help demonstrate how you would
use the above:
[Else_if | jmp I5> | I0: | cmp #1 #3 | jn#2 I0>]
[.Else_if | jmp I6>> | I1: | cmp #1 #3 | jn#2 I1>>]
[..Else_if | jmp I7>> | I2: | cmp #1 #3 | jn#2 I2>>]
[...Else_if | jmp I8>> | I3: | cmp #1 #3 | jn#2 I3>>]
Okay, enough poking fun at the unreadable mess
these scheme produces (actually, the above
*could* be written in a more readable fashion,
but this *is* the code that ships with RosAsm,
so it's not an unfair example).
#1..#9 are how you reference individual macro
parameters in RosAsm. Unlike most other
assemblers, RosAsm does not let you assign names
to macro parameters, you refer to them using
their numeric parameter position. This means that
you have to type things like "cmp #1 #3" rather
than something a little more readable like
cmp LeftOperand RightOperand
Worse still, you'll soon see that #1 or #3 could
actually refer to different arguments. Confusing,
no?
Well, we need to show that MASM and HLA can also
refer to arguments numerically. In MASM, this is
done use the XXX:VARARGS formal macro parameter
declaration. This declaration will package a list
of macro parameters into a single "text equate"
which you can pick apart using operators like
MASM's IRP macro facility. It is kind of a PITA,
but you can write some "helper macros" to pick
off individual elements from such a list. E.g.,
; If you want the nth item, you could do
; something like this:
i = 0
IRP curItem, <listOfItems>
if i eq n
theItem textequ <curItem>
exitm
endif
i = i + 1
endm
In HLA, this is really easy. Just declare a
variable-length argument as follows:
#macro someMacro( varArgs[] );
Now you can access the nth argument using a
compile-time expression like "varArgs[n]".
As you can see, this RosAsm facility is easily
duplicated using MASM or HLA's macro facilities.
#F, #L, and #n are just special cases of #1..#9.
They're easy enough to simulate by simply
tracking the number of elements in the var-args
lists in MASM and HLA (very easy to do with both
assemblers).
RosAsm does not support a generalized
compile-time loop. It provides the #-n and #+n
tokens to create loops on macro parameters. These
loops have all kinds of restrictions, such as the
fact that they always repeat from the first
instruction in the macro (no such restrictions in
MASM and HLA on their generalized compile-time
loops). In MASM, you can use the FOR or IRP loops
to do the same thing that #+n and #-n do, in HLA
you can use the #while and #for loops to achieve
this. Not only are the MASM and HLA facilities
capable of doing everything that the RosAsm loop
control does, but they can do a lot more, as
well.
The #m>n and #L>n facilities provide a way of
copying macro parameters around. These operators
are used for collecting a set of parameters into
a single string (generally for use in feeding
that string to another macro as the parameter
list for that other macro). #m>n extracts a
"slice" from the current macro list (e.g., #5>8
means "create a new list of items using
parameters five through 8 and #L>2 means "extract
all parameters from #2 through the end of the
list).
Again, in MASM once can use the FOR/IRP loop to
extra items and recombine them to pass on to
another macro, in HLA it's a trivial matter to
use a compile-time #FOR loop to extract those
parameter items. For example, consider the
following HLA macro that does just this:
#macro extract( list, start, stop ):index;
[
list[0]
#for( index := start+1 to stop )
,list[index]
#endfor
]
#endmacro
Now, an invocation of the form:
extract( someList, 5, 8 )
produces an array of strings corresponding to the
fifth through eighth items in "someList".
The #x token is an artifact that exists because
RosAsm doesn't have true looping facilities nor a
decent numeric equate facility. In HLA and MASM,
you can easily simulate this by running a counter
during a loop (assuming you're not using a #FOR
loop that has a loop counter already). E.g., in
MASM:
x = 1
while( some_condition )
;use x's value as the loop counter.
x = x + 1
endw
The "#X=5" token exists because RosAsm doesn't
support fixed arguments in the macro parameter
list. This facility is completely unneeded in
MASM and HLA as you *can* specify required
parameters, but just to demonstrate that you
*can* simulate this, here's the HLA code:
#if( @elements( varArgs ) <> 5 )
#error( "Must have exactly five arguments" )
#endif
In MASM, you can use the FOR/IRP loop to count
the parameters and then use conditional assembly
as above to print an appropriate error message.
The #1! item is a real kludge that exists because
RosAsm doesn't have reasonable string processing
facilities for operating on macro parameters.
Both HLA and MASM provide a "substring" function
that lets you extract any number of characters
from any position in a macro parameter. MASM and
HLA also provide a wide range of other string
processing functions that let you do all kinds of
things with the macro parameters, things that
just cannot be done with RosAsm.
&1= is another huge kludge. Here's what BUA has
to say about this construct:
"The Macro Parser manages 100 internal Data
storages (128 bytes each) where you can store
what you want, under a text form,"
IOW, you've got 100 *global* variables, limited
to 128 bytes each. In HLA and MASM, you can
create as *many* symbols as you like using
standard identifiers, and in HLA there is no
practical limit on the size of the text
associated with the symbol (I have no idea if
there are limits placed on MASM textequ strings).
The worst part about these objects in RosAsm is
that they are *global*. The programmer has to
manage their use and make sure not to use the
same global object in two macros concurrently. In
MASM and HLA, of course, you can create *local*
symbols that do a much better job of this.
RosAsm also "sorta" has a local symbol, it's &0=,
but it's almost useless when compared to the
power and flexibility of HLA and MASM's local
macro symbol facilities.
NOPE: Just say "NOPE"!
In MASM and HLA you can create all the empty
macros your heart desires without having to
resort to kludgy syntax (like having to specify
"NOPE").
RosAsm only supports one level of nesting in
macro definitions. Worse, because RosAsm equates
and macros use a similar syntax, you cannot
define any equates in a nested macro definition.
No such limitation exists in HLA or MASM. You can
nest macro declarations as deeply as you dare.
As noted above, RosAsm doesn't support
"macro-local" labels. BUA suggests that you come
up with some naming convention to avoid naming
comflicts that inevitably arise when using
macros. Fortunately, no such kludges are
necessary in MASM and HLA as you can easily
create identifiers that are local to each
invocation of the macro.
>From BUA:
"'&' is a very powerful and unique feature of
RosAsm Macros Parser. It allows you to build
organizations that would be fully impossible with
another Assembler Macros Parser. As this feature
is strictly limited to 9 storages, do not spoil
them with few use managements. Try to write your
Macros in a way that allow them to run with as
few '&x' as possible."
This statement is completely false. The &n
construct provides *weak* support for
compile-time text variables. Both MASM and HLA
support an unlimited number of textual objects,
along with a wide array of compile-time text
processing functions that make it very easy to
construct whatever item you like. Continuing in
BUA:
"You are responsible for the management of these
storages. Pay attention to not reusing an already
in use storage. Each time you want a new one,
verify carefully that is is not used by another
Macro. This kind of error is difficult to point
out when done. The 'Proc' Macros I provide use 3
storages, upper 'For' uses 2 and 'Multi If' only
1."
You don't have this problem when using MASM or
HLA. Just create a new identifier (or use a local
identifier in a macro) and you're in business.
Management of the "storages" is trivial.
>From BUA:
"The Macro Parser manages 100 internal dWords
Counters, that have been implemented at the same
time as the Conditional Macros parser. Like the
Internal Strings (&0 and &1 to &99), the Internal
Counters are from &&0 to &&99."
This is completely crazy. As best I can tell,
RosAsm's equates facilities are textual based
only. That's the only reason I can think of why
you would need this crazy "&&n" syntax. In
assemblers like MASM and HLA, if you want a
counter, simply declare a compile-time variable
(numeric equate) and you're in business. And in
MASM and HLA, you're not limited to dword values,
you can use any value the assembler supports
(e.g., strings, reals, etc.).
You can also get an idea of the kludge that must
exist in the RosAsm scanner when you read this in
BUA:
---------------------
Storing
... | &&1=25 |...
Notice that, what is stored, here, is a real
dWord, not a String, like with the internal
Strings
There must not be any space in between the
Counter and the equal Char:
... | &&1 = 25 |... ; Wrong!!!
Though you can provide a space after the Equal
Char (required anyway, for Strings defintion):
... | &&1= 'A' |...
-----------------------
Sometime, Rene can explain the craziness behind
this syntax.
RosAsm recently added conditional assembly to its
repretoire. A *huge* improvement over past
versions that were missing this important
facility. Unfortunately, RosAsm doesn't allow the
use of generic boolean expressions in the
conditional assembly statements. You can test a
few conditions such as macro parameter type and
test the values of numeric and string variables
(the "&n" stuff), and that's about it. MASM and
HLA provide *full* feature conditional assembly
with arbitrary expressions. HLA and MASM both
provide a set of compile-time functions that
easily emulate all of the facilities that the
RosAsm conditional assembly statements test for
(such as argument type, whether it's a register,
symbol, constant, and so on).
In conclusion, there's not a single feature in
the RosAsm assembler that cannot be easily
duplicated using facilities in HLA and MASM. MASM
and HLA, on the other hand, have a ton of
features that RosAsm is incapable of reproducing
(compile-time loops, compile-time arrays, string
handling functions, and so on and so forth).
Clearly, RosAsm's macro facilities aren't even
close to these other assemblers. Yes, RosAsm's
macro facilities could be considered powerful in
the absence of these other assemblers, but the
fact that such assemblers exist (and in the case
of MASM, have existed for the past 20 years)
makes the claim of RosAsm's macro power
laughable.
Cheers,
Randy Hyde
NoDot
> Hi All,
>
> [snip]
As the first person to reply to this, good job. Now I can't really wait
to read Betov's reply to this.
> Cheers,
> Randy Hyde
NoDot,
...
Sevag Krikorian
My guess is that it will be a single sentence insult, confirming the
truth of the entire post.
--
[kain]
http://www.geocities.com/kahlinor
hutch--
You have a penchant for the truth with great economy. :)
Lets hope that FEARFULL LEADER actually comes clean and produces the
macro he claimed no other preprocessor could create.
No-one would wish to see him denied the chance of showing all of those
HLA, MASM, TASM, FASM, NASM and GoAsm users how "powerful" RosAsm
macros really are and how clear and easy to read they are.
Regards,
hutch at movsd dot com
Evenbit
rand...@earthlink.net wrote:
>
> #macro extract( list, start, stop ):index;
>
> [
> list[0]
> #for( index := start+1 to stop )
>
> ,list[index]
> #endfor
> ]
> #endmacro
>
Shouldn't this be:
#macro extract( list, start, stop ):index;
[
list[start]
#for( index := start+1 to stop )
,list[index]
#endfor
]
#endmacro
Nathan.
Betov
news:1120881408.4...@g47g2000cwa.googlegroups.com:
> [...]
The purpose of a Macros System, in an Assembler like
RosAsm, is to open the door to HLLisms, and particulary
to HLL-Style Constructs.
This goal is achieved by the fact that the RosAsm users
write Sources that, at a formal point of view, are way
closer to HLL-Styles, than what can be read in any other
Assembler Source.
If this goal has been achieved this is, first because
the RosAsm Macros are simple to use and to maintain,
and this is one of the reasons why, as opposed to what
can be seen in the other Assemblers Sources, the RosAsm
user tend - halas, sometimes... - to develop their own
private Language.
So, i have no effort, at all, to do, by playing the bigger
dig game with an unsignificant individual like you:
As i already told you several times, i do NOT take
challenges, because i do not need to, and because i have
serious work to do. The product itself is a challenge for
the others, not the reverse.
Before attacking a real Product like RosAsm, you'd better
... do something real, instead of spoiling your time at
Propaganda. Whatever absurd critics you could do on RosAsm
Macros, Assembler, Disassembler, Debugger, sources Editor,
Resources Editor, and so on... this will never make your
ridicoulous HLL Pre-Parser any better.
:)
Yes, RosAsm Macros are very powerfull, and have tons
of particular features that are designed to build what
we need to built. It is a _practical_ system, under
continious improvement, and certainaly not a demential
theory about how to enable this or that, that nobody
will ever use... But do not hope that i am going to offer
you any tribune for your insane propaganda, on that subject.
Again, _you_ have everything to prove, as long as you never
did anything but selling yourself, and i have nothing to
prove, as long as my Megas of working Assembly are there
to show facts.
:)
Betov.
rand...@earthlink.net
Evenbit wrote:
> [
>
> list[start]
^^^
Yep, sorry.
Cheers,
Randy Hyde
rand...@earthlink.net
Betov wrote:
> rand...@earthlink.net écrivait
> news:1120881408.4...@g47g2000cwa.googlegroups.com:
>
> > [...]
>
> The purpose of a Macros System, in an Assembler like
> RosAsm, is to open the door to HLLisms, and particulary
> to HLL-Style Constructs.
Well, most assemblers with powerful macro subsystem
provide macros to open the door to many possibilities,
not just HLLisms. But I can let that slide because if you
can do HLLisms good, then you can do many other things
well, too.
Now let's assume that your statement "The purpose of a
Macros System...is to open the door to HLLisms, and
particulary to HLL-Style Constructs" is true, that this
is the purpose of a macro processor. This being the case,
RosAsm does *not* do a very good job of fulfilling the
needs of people who use macros. Most HLL control
constructs are "nestable". They use a push-down automata
(i.e., a stack) to implement context-free language
constructs. A classic example is the
"if..then..elseif..else..endif" statement. In a
context-free control structure, some initial keyword
(like "if") is *exactly* matched by a terminating keyword
(like "endif"). RosAsm doesn't provide an internal stack
for such constructs, nor does it (AFAICT) provide any way
for a programmer to create their own stack to track
information you'll need to handle nested constructs. As a
result, you wind up having to write kludges like this:
[.If | cmp #1 #3 | jn#2 I0>>]
[..If | cmp #1 #3 | jn#2 I1>>]
[...If | cmp #1 #3 | jn#2 I2>>]
[....If | cmp #1 #3 | jn#2 I3>>]
[.....If | cmp #1 #3 | jn#2 I4>>]
[......If | cmp #1 #3 | jn#2 J0>>]
[.......If | cmp #1 #3 | jn#2 J1>>]
[........If | cmp #1 #3 | jn#2 J2>>]
[.........If | cmp #1 #3 | jn#2 J3>>]
[..........If | cmp #1 #3 | jn#2 J4>>]
[.End_If | I0: | I5:]
[..End_If | I1: | I6:]
[...End_If | I2: | I7:]
[....End_If | I3: | I8:]
[.....End_If | I4: | I9:]
[......End_If | j0: | j5:]
[.......End_If | j1: | j6:]
[........End_If | j2: | j7:]
[.........End_If | j3: | j8:]
[..........End_If | j4: | j9:]
And use a different macro invocation for each nested
call. This is *simple*? Contrast this with how you would
do this in HLA:
#macro _if( expr ):endifLbl;
// jf: "jump if false, compiles expression
// and branches if the expression evaluates
// false.
jf( expr ) endifLbl;
#terminator endif;
endifLbl:
#endmacro
Much simpler to write, read, maintain, and use than the
RosAsm kludge. And it has the added bonus of being
nestable to *any* reasonable depth, not just 10 levels.
10 levels may seem like a tremendous amount, and it's
doubtful any *human* would exceed this depth, but keep in
mind that *MACROS*, particularly recursive ones, can
easily extend this depth. And lest you think that macros
might not use macro invocations of HLL-like control
structures, I would point out the macro you've written in
BUA that attempts to hide the above kludge:
[If | &6=&6. | &6If #1>L]
[Else_If | &6Else_If #1>L]
[Else | &6Else]
[End_If | &6End_If | &6=&6!]
(quick, everyone, is it obvious what this does? Aren't
RosAsm macros simple, easy to read, easy to understand,
and easy to maintain?)
Bottom line is that without a stack, you cannot properly
handle context-free control structures. If you really
designed RosAsm's macro facilities to handle HLL-like
control structures, I would have thought you'd have
provided some ability for the user to create and use a
stack, or better yet, made the stack implicit (as I've
done with HLA). Note that both FASM and NASM provide a
stack as part of their macro processors that programmers
can use (to push and pop local symbols). MASM and TASM
don't provide an explicit stack, but they do provide the
tools for programmers to create their own. I guess you
could claim that the previous macro implements a stack (a
stack of "." characters), but it's very limited and you
have to write individual macros for each stack item in
order for this scheme to work. Not very impressive. Of
course, God help you if you accidentally reuse the &6
global variable in another macro somewhere. Given the
global nature of your &n strings, this macro has pretty
much grabbed &6 for use *only* by the IF macro. Not a
pretty design at all.
>
> This goal is achieved by the fact that the RosAsm users
> write Sources that, at a formal point of view, are way
> closer to HLL-Styles,
For years, I've been hearing from people (including
yourself) that this is *bad*. Allowing people to write
code in a HLL-like style rather than forcing them to
write low-level assembly language defeats the purpose of
assembly language programming. Of course, I agree with
you (as does Microsoft and TASM). But it's interesting
that you've been the prime critic of HLA, claiming that
it's a HLL and claiming that HLA programmers are not
assembly language programmers, and then you turn around
and suggest that the purpose of RosAsm's macros is to
allow people to "not write assembly language." Why is it
okay for RosAsm users to use macros to avoid writing
assembly and this is not okay for assemblers like MASM,
TASM, and HLA?
Your story is a bit inconsistent here.
> than what can be read in any other
> Assembler Source.
Yes, the RosAsm code:
.If D@Message = &WM_CLOSE
call 'USER32.DestroyWindow' D@Adressee
.Else_If D@Message = &WM_DESTROY
call 'User32.PostQuitMessage' 0
.Else_If D@Message = &WM_COMMAND
If D@wParam = M00_Exit
call 'User32.SendMessageA' D@Adressee &WM_CLOSE 0 0
is so much more readable than the MASM code:
.if Message == WM_CLOSE
invoke DestroyWindow, Adressee
.elseif Message == WM_DESTROY
invoke PostQuitMessage, 0
.elseif Message == WM_COMMAND
.if wParam == M00_Exit
invoke SendMessageA, Adressee, WM_CLOSE, 0, 0
Care to try again?
All you're attempting to do is *catch up* with existing
assemblers like MASM, TASM, and HLA. The interesting part
is that you're in the middle of "no man's land" with
your macros. At one extreme are the programmers who
refuse to use HLL constructs in their assembly code. They
certainly aren't interested in your lame macro/HLL
capabilities. At the other extreme are people who want to
use the HLL-like capabilities, but much prefer the
additional power and capabilities of assemblers like HLA,
MASM, and TASM over the half-way approach that RosAsm
uses.
>
> If this goal has been achieved this is, first because
> the RosAsm Macros are simple to use
Yes, having to manually specify the nesting depth of a
context-free control structure makes it "simple to use"
-- NOT!
> and to maintain,
Ooooooh Yeah!
Deciphering macros like
[StrucPtrs | {#3 ebp+#2+#F} | #+2]
[Structure | {#1 ebp-&2-4} | sub esp #2+4 | mov D$#1 esp | StrucPtrs
0-&2-#2-4 #L>3]
is trivial. (quick, how many people other than the
original author of this macro can tell me what it does?)
> and this is one of the reasons why, as opposed to what
> can be seen in the other Assemblers Sources, the RosAsm
> user tend - halas, sometimes... - to develop their own
> private Language.
This is the funniest part yet. You are constantly
accusing HLA users of not being "real assembly
programmers" because they tend to use the HLL-like
constructs present in the language. Yet it's okay for
RosAsm users to use the "private language" you've created
for them and even extend that "private language" off in
different directions. What makes them "real" assembly
programmers if they're using HLL-like control constructs
rather than pure machine instructions? How is the fact
that a RosAsm user is writing IF statements using macros
that *you* wrote any different than an HLA user writing
IF statements using macros that *I* wrote?
Again, your message is a bit inconsistent here.
>
> So, i have no effort, at all, to do, by playing the bigger
> dig game with an unsignificant individual like you:
Of course not. You don't like losing any more than anyone
else does.
>
> As i already told you several times, i do NOT take
> challenges,
Because you know you'll lose.
> because i do not need to,
Because no one believes what you say anyway. So why prove
they were correct in not believing your claims?
> and because i have
> serious work to do.
OTOH, my original post *was* a challenge and you
responded to it via your post. Clearly you *do* have the
time to respond to challenges. If you *really* had
serious work to do, why do you waste so much time posting
to this newsgroup?
> The product itself is a challenge for
> the others, not the reverse.
HaHaHaHaHa.
RosAsm is a challenge to products like HLA, MASM, TASM,
FASM, NASM, and GoAsm about as much as a cockroach is a
challenge to an Elephant.
>
> Before attacking a real Product like RosAsm,
I should wait for RosAsm to become a real product :-)
Currently, it is a toy. At best, a broken toy.
> you'd better
> ... do something real, instead of spoiling your time at
> Propaganda.
Whatever you say....
You might try following your own advice sometime. You'd
probably *have* a decent product by now if you spent your
time working on RosAsm rather than posting to newsgroups.
> Whatever absurd critics you could do on RosAsm
> Macros, Assembler, Disassembler, Debugger, sources Editor,
> Resources Editor, and so on...
Personally, I don't care about your disassembler,
debugger, sources editor, and resource editor. They have
nothing to do with assembly language.
Then again, I don't really care about your macros or
assembler, either. 'Cause they're just trivial little
toys that pale in comparison to other assemblers
available today.
> this will never make your
> ridicoulous HLL Pre-Parser any better.
Well, you're absolutely right. But stop to consider that
your constant attacks on other products and people are
not making RosAsm any better either. Indeed, the main
effect your attacks have is that they scare people away
from your product and waste your valuable time that you
could be using to improve RosAsm. And given the state
RosAsm is in (that is, in need of improvement), it's a
crime that you waste so much time around here.
Attacking people and products will not make your product
any better. Nor will it make those other products any
worse. All it does is prevent you from using that time to
improve your own product.
True, the time I waste in this newsgroup also prevents me
from improving my product, but HLA's feature set is
*sooooo* far ahead of RosAsm's that I can afford a break
now and then. You are trailing the pack, you've got a lot
of distance to make up.
>
> :)
>
> Yes, RosAsm Macros are very powerfull, and have tons
> of particular features that are designed to build what
> we need to built. It is a _practical_ system, under
> continious improvement, and certainaly not a demential
> theory about how to enable this or that, that nobody
> will ever use...
Now see? If you'd stated that originally, rather than
simply claiming that RosAsm macros are "powerful", there
wouldn't be any discussion on the subject. Stating that
"RosAsm macros are powerful enough for RosAsm users" is
probably quite factual. It may not say much about the
RosAsm user base, but you won't find anyone arguing with
you about it. In the future, you might try sticking to
the facts rather than claiming your macro system is more
powerful than other assemblers.
> But do not hope that i am going to offer
> you any tribune for your insane propaganda, on that subject.
Whatever you say.
>
> Again, _you_ have everything to prove, as long as you never
> did anything but selling yourself, and i have nothing to
> prove, as long as my Megas of working Assembly are there
^^^^^^^
> to show facts.
Don't you think it would be a good idea to first get your
assembler *working* before you make such claims? Have
you fixed the bug that causes RosAsm to crash if you
invoke your "message" macro 128 times in a row (from the
cmtest.exe file)?
Cheers,
Randy Hyde
Betov
@f14g2000cwb.googlegroups.com:
> [...]
How crual, isn't it, ass-hole, to have to show
so much hate against a product that makes you
look like a pathetic clown...
:)
Betov.
Betov
>How crual, isn't it, ass-hole, to have to show
>so much hate against a product that makes you
>look like a pathetic clown...
Also all HLL construct macros wrote by myself or my many users are
viewable in the source editor and not hidden away internally in an
assembly compiler. So there is directly a 1 to 1 translation.
:)
Betov.
Betov
4ax.com:
I do not know what this means... but i am not the author
of this post.
Betov.
Alex McDonald
>
> I do not know what this means... but i am not the author
> of this post.
>
>
> Betov.
>
> < http://rosasm.org >
True, it looks like an NTL cable user in the UK (Nottingham) spoofed
this post; obviously forgot that you can spoof only so much.
cpc1-scun3-4-0-cust216.nott.cable.ntl.com on 82.16.144.216
You might like to complain to his or her ISP with a copy of the
headers; I think NTL cable IP addresses are fixed, so they'll know who
it is.
--
Regards
Alex McDonald
Woody
<alex...@btopenworld.com> wrote:
>True, it looks like an NTL cable user in the UK (Nottingham) spoofed
>this post; obviously forgot that you can spoof only so much.
>
>cpc1-scun3-4-0-cust216.nott.cable.ntl.com on 82.16.144.216
>
>You might like to complain to his or her ISP with a copy of the
>headers; I think NTL cable IP addresses are fixed, so they'll know who
>it is.
Don't be so absurd over a bit of fun!!!
Betov
news:1120941959.1...@g43g2000cwa.googlegroups.com:
> You might like to complain to his or her ISP with a copy of the
> headers; I think NTL cable IP addresses are fixed, so they'll know who
> it is.
Boooffff... If someone is amused with this...
Betov.
Woody
Or amused with constantly swearing in every other post?
Sevag Krikorian
with. Note: this is not meant to be a particularly "powerful" macro
demonstrating the best of HLA's macros system.
program funwithmacros;
#include ("stdlib.hhf")
#macro auxreg ( _letter_ ):_stringit_, _autolabel_;
/* this macro will create an area of static memory
addressable like a register. you supply
a letter f..z. assuming the letter entered
is 'j', the macro creates:
a 4 byte memory addressable by the following
labels:
jl byte 0 (LO byte)
jh byte 1 (HO byte of LO word)
jx byte 0-1 (LO word)
ejx byte 0-3 (entire dword)
ej byte 2-3 (HO word)
since HLA allows memory-memory moves using
the 'mov' instruction, it's perfectly legal
to write:
mov (jl, jh);
it's possible to split the high order word
into 2 addressable bytes as well, but that
would be too 'messy'
also possible, yet not too messy is to
simulate a 64-bit "register"
*/
// start with some errorchecking
?_stringit_ := @string (_letter_);
#if ( @length (_stringit_) > 1 )
#error (":auxreg: please enter a single letter argument");
#elseif ( _stringit_ < "f")
#error (":auxreg: you entered a reserved letter, use f .. z");
#elseif ( _stringit_ <="Z")
#error (":auxreg: only lower case symbols supported");
#endif
// error checking complete, now create the auxiliary register
?_stringit_ := @string(_letter_)+"l";
@text(_stringit_) :byte; @nostorage;
?_stringit_ := @string(_letter_)+"x";
@text(_stringit_) :word; @nostorage;
?_stringit_ := "e"+ @string(_letter_)+"x";
@text(_stringit_) :dword; @nostorage;
// need to skip a byte here because of the
// "union" above
_autolabel_ :byte;
?_stringit_ := @string(_letter_) +"h";
@text(_stringit_) :byte;
/* in auxiliary registers, you can even address the high order word! */
?_stringit_ := "e"+ @string(_letter_);
@text(_stringit_) :word;
#endmacro
static
auxreg (f); // create auxiliary register: efx
auxreg (g); // create auxiliary register: egx
endstatic;
begin funwithmacros;
mov (-1, efx);
stdout.put (efx,nl);
mov ($10, fl);
mov ($20, fh);
stdout.put (efx,nl);
mov (fx, ef);
stdout.put (efx,nl);
mov (ef, eg);
stdout.put (egx, nl);
end funwithmacros;
//====================================================================
The big limitation here is obvious, these aren't real registers so
if someone wants to use memory-memory logical operations directly
on auxiliary registers, like xor (egx, egx); the instruction set has
to be modified by more macros to accomodate (too much work!)
The other limitation is that auxreg can't be used to create temporary
'registers' on the stack. It would be much more useful if it did.
I'm not experienced enough with the HLA macros system to know if this
is possible. It does seem possible with HLA's ability to specify var
offsets. Something I'll have to look into.
--
[kain]
http://www.geocities.com/kahlinor
Randall Hyde
"Sevag Krikorian" <kahl...@nop.yahoo.com> wrote in message
news:daplro$qov$1...@domitilla.aioe.org...
> I was bored at work and decided to write a fun macro to play around
> with. Note: this is not meant to be a particularly "powerful" macro
> demonstrating the best of HLA's macros system.
>
> The other limitation is that auxreg can't be used to create temporary
> 'registers' on the stack. It would be much more useful if it did.
> I'm not experienced enough with the HLA macros system to know if this
> is possible. It does seem possible with HLA's ability to specify var
> offsets. Something I'll have to look into.
Hi Sevag,
Here's a version that supports VAR objects (and STORAGE and READONLY, for
that matter). It takes advantage of the HLA "FORWARD" directive to grab a
label declared earlier on the line. It simply defines a DWORD object and
then creates text equates to reference bytes and words within that dword.
Cheers,
Randy Hyde
program funwithmacros;
#include ("stdlib.hhf")
#macro auxreg:
_theLetter_,
_strLetter_,
_byteLow_,
_byteHigh_,
_word_,
_dword_;
// Allow HLA-style declarations, using "auxreg" as a type.
// Begin by capturing the symbol immediately before the
// auxreg "type":
forward( _theLetter_ );
// Convert _theLetter_ from text to string:
?_strLetter_ := @string( @text( @string( _theLetter_ )));
/*
this macro will create an area of static memory
addressable like a register. you supply
a letter f..z. assuming the letter entered
is 'j', the macro creates:
a 4 byte memory addressable by the following
labels:
jl byte 0 (LO byte)
jh byte 1 (HO byte of LO word)
jx byte 0-1 (LO word)
ejx byte 0-3 (entire dword)
ej byte 2-3 (HO word)
since HLA allows memory-memory moves using
the 'mov' instruction, it's perfectly legal
to write:
mov (jl, jh);
[Note: no it is not. memory-memory moves are only
valid for 16-bit and 32-bit objects. The above is an eight-bit
move which is illegal.]
it's possible to split the high order word
into 2 addressable bytes as well, but that
would be too 'messy'
also possible, yet not too messy is to
simulate a 64-bit "register"
*/
// start with some errorchecking
#if ( @length (_strLetter_) > 1 )
#error (":auxreg: please enter a single letter argument");
#elseif ( _strLetter_ < "f")
#error (":auxreg: you entered a reserved letter, use f .. z");
#elseif ( _strLetter_ <="Z")
#error (":auxreg: only lower case symbols supported");
#endif
// error checking complete, now create the auxiliary register
?_dword_ := 'e' + _strLetter_ + 'x';
?@text( _strLetter_ + 'x') :text := "(type word " + _dword_ + ")";
?@text( 'e' + _strLetter_) :text := "(type word " + _dword_ + "[2])";
?@text( _strLetter_ + 'l') :text := "(type byte " + _dword_ + ")";
?@text( _strLetter_ + 'h') :text := "(type byte " + _dword_ + "[1])";
@text(_dword_) : dword
#endmacro
static
f:auxreg; // create auxiliary register: efx
g:auxreg; // create auxiliary register: egx
var
h:auxreg;
begin funwithmacros;
mov (-1, efx);
stdout.put (efx,nl);
mov ($10, fl);
mov ($20, fh);
stdout.put (efx,nl);
mov( 0, hx );
mov( $1234, eh );
stdout.put( ehx, nl );
end funwithmacros;
Betov
$8f7....@newsread1.news.pas.earthlink.net:
> since HLA allows memory-memory moves using
> the 'mov' instruction, it's perfectly legal
> to write:
> mov (jl, jh);
One minute of silence, for the poor beginners falling
into your death traps...
Betov.
Sevag Krikorian
Freudian slip assmuncher. Need we point out everytime *you*
made grammatical errors? Or how about all those times you
invent new words that nobody else knows about?
It's back to the drawing board to fix RotAsm for you. Yes, it is RotAsm
since you can't ethically associate your crap with the
ReactOs project anymore. Poor Rene. It seems that *nobody*
wants you around.
--
[kain]
http://www.geocities.com/kahlinor
Sevag Krikorian
> [Note: no it is not. memory-memory moves are only
> valid for 16-bit and 32-bit objects. The above is an eight-bit
> move which is illegal.]
>
Yes, thanks for pointing that out, as I was writing this at work, I was
at times interrupted by other tasks that needed to be done :)
> ?_dword_ := 'e' + _strLetter_ + 'x';
> ?@text( _strLetter_ + 'x') :text := "(type word " + _dword_ + ")";
> ?@text( 'e' + _strLetter_) :text := "(type word " + _dword_ + "[2])";
> ?@text( _strLetter_ + 'l') :text := "(type byte " + _dword_ + ")";
> ?@text( _strLetter_ + 'h') :text := "(type byte " + _dword_ + "[1])";
>
> @text(_dword_) : dword
>
> #endmacro
Great! It seems that I was using the wrong approach from the start
with my use of "unions." This does make things _much_ easier!
--
[kain]
http://www.geocities.com/kahlinor
Betov
@domitilla.aioe.org:
> Need we point out everytime *you*
> made grammatical errors?
No. We have enough with the impressive success
of Hyde.
:))))))))))))))))))))))))))))))))))))))))))))))
Betov.
PS. How goes your Source Editor, written with HLA,
for LuxAsm, ass-hole? As great as Hyde?
:))))))))))))))))))))))))))))))))))))))))))))))
Did you understand how to manage the Row Pos of the
Caret?
:))))))))))))))))))))))))))))))))))))))))))))))
Betov.
Betov
@domitilla.aioe.org:
> Great! It seems that I was using the wrong approach from the start
Indead...
:)))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
Betov.
hutch--
Poor old FEARFULL LEADER is still green with envy about how smart Randy
Hyde is. Now look on the bright side, if you can con enough decent
programmers to rewrite that broken pile of crap so it actually works,
at least someone may think you could be as smart as Randy Hyde if you
worked at it long enough.
Muhahahaha
Sevag Krikorian
> Sevag Krikorian <kahl...@nop.yahoo.com> écrivait news:darlo0$529$1
> @domitilla.aioe.org:
>
>
>>Need we point out everytime *you*
>>made grammatical errors?
>
>
> No. We have enough with the impressive success
> of Hyde.
>
> :))))))))))))))))))))))))))))))))))))))))))))))
>
>
> Betov.
>
> < http://rosasm.org >
>
> PS. How goes your Source Editor, written with HLA,
> for LuxAsm, ass-hole? As great as Hyde?
>
> :))))))))))))))))))))))))))))))))))))))))))))))
>
I don't have a source editor for LuxAsm and never
made any plans to write one.
My source editor is for the next major version of
HIDE to make it portable to Linux, and it's a long
way off for 2 reasons:
1. I don't know much about Linux, so I have to spend
a lot of time gathering documents and actually reading
and making demo programms to understand them.
2. I don't much like Linux, prefering the much superior
(IMO) operating system of Windows, so it takes me a while
to motivate myself to work on it. This means Windows
projects take priority for me.
Further, I'm still undecided on the basic format.
If you actually want to make a reasonable discussion
on it like an adult, then I invite you to join in with
your opinions. I never hold a grudge beyond my last 'post.'
1. Line based: I already have a working prototype on this model.
Pros:
-very easy to code
-very fast
cons:
-wastes memory: 12 bytes per line in memory (line ptr, max len,
cur len). Even more if I make a 64 bit version.
2. Buffer based: C (the programmer) suggested this and I like it.
Allocate memory in page sized buffers (4096 bytes).
Pros:
-more memory efficient
Cons:
-slower tha line-based
-harder to code
-too many things need to be modified with each stroke.
I'm working on a prototype for this, but it's a pain.
3. RosAsm style. If my memory serves me, you allocate
1MB buffers, copy/paste to/from the "main" source as needed.
Pros:
-more memory efficient than #1 and #2
-less things to worry about than #2
Cons:
-a bit slower than #2 (on large sources)
-you probably need a monolitic style with TITLES
like the system in RosAsm to make it work.
> Did you understand how to manage the Row Pos of the
> Caret?
>
Row pos for a line based system is trivial.
--
[kain]
http://www.geocities.com/kahlinor
Betov
@domitilla.aioe.org:
> I don't have a source editor for LuxAsm and never
> made any plans to write one.
> My source editor is for the next major version of
> HIDE to make it portable to Linux, and it's a long
> way off for 2 reasons:
>
> 1. I don't know much about Linux, so I have to spend
> a lot of time gathering documents and actually reading
> and making demo programms to understand them.
>
> 2. I don't much like Linux, prefering the much superior
> (IMO) operating system of Windows, so it takes me a while
> to motivate myself to work on it. This means Windows
> projects take priority for me.
>
> Further, I'm still undecided on the basic format.
> If you actually want to make a reasonable discussion
> on it like an adult, then I invite you to join in with
> your opinions. I never hold a grudge beyond my last 'post.'
Mind you, even though i cannot ignore the fact that
you contributed to Master Pdf promotion, - which is
an unforgivable sin - if you had switched to LuxAsm,
and developed a Sources Editor, for LuxAsm, i would
have followed-up on this interresting technical
discussion.
I had an impression that you were comming to reason,
and that you were going to switch to LuxAsm, what
would have been a huge progress, as, -if i heard well-,
LuxAsm is being written with NASM, that is an Assembler.
Unfortunately, again and again, you show your amaizing
stupidity, by working for Hyde, this is to say, against
Assembly, and i can just regret, that C guy, gave you
any recommandation.
Betov.
Sevag Krikorian
Figures. You have no intention of actually discussing
assembly programming, all you care about is stirring up
trouble. But we are all aready aware of that, I just
thought I'd extend yet another peace offering.
Oh well. BTW, I'm not "working for Hyde" or anybody
for that matter. I work for myself and if any of that
work should assist others, others being _anybody_, I have
absolutely no problems with that.
--
[kain]
http://www.geocities.com/kahlinor
Betov
@domitilla.aioe.org:
> Figures. You have no intention of actually discussing
> assembly programming, all you care about is stirring up
> trouble. But we are all aready aware of that, I just
> thought I'd extend yet another peace offering.
???!!!... By proposing a discussion intending to
_support_ the Randall Hyde HLL Pre-Parser?
If that is the way you are "peace offering", please,
offer me a gun.
Betov.