Catagories of Assembly Languages
NoDot
This is not a thread about RosAsm.
This is not a thread about whether or not HLA is an assembler.
This is not a promotion for *any* product whatsoever.
This thread is about the catagories of assembly languages.
It is *NOT* about their implimentations, whatever they may be.
A brief outline so you know what's to come:
1) Assembly Languages
2) Macro Assebmly Languages
3) Semi-High Level Assembly Languages
4) High Level Assembly Languages
5) What "Assembly Language" means in "normal" usage.
6) Conclusion
1) Assembly Languages
An Assembly Language (also know as a symbolic assembly language) is a
lnguages that directly translates down into the processor's instructions
and includes support for symbolic lables for ease of use, and assembler
directives, which change depending on the output format and the
assembler's option level.
I know of none for the x86 family of processors and runs of any known OS.
2) Macro Assembly Language
A Macro Assembly Language is a dirivitive of Assembly Languages. It
includes the same abilities of assembly languages and also adds
capabilities such as equates, macros, and symbolic constants. The level
of power offered by these features is dependant opon the assembler.
Macro Assembly Languages include (these refer to the languages) NASM,
and I can't think of any others.
3) Semi-High Level Assembly Languages
Simi-High Level Assembly Languages are often forgotten, and lumped
together with high level assembly languages. Semi-high levle assembly
languages offer the same capabilities as macro assembly languages, but
add support for the HL-like features, data typing and composite data
types. Data types are supported for attempting to assist in error
tracking and correction. A semi-high level assembly language's support
for composite data types include support for HL declarations and usage
of things such as records/structures, unions, and namespaces, though not
all of these need to be supported.
Examples of semi-high level assembly languages include GoAsm and FASM.
4) High Level Assembly Languages
A high level assembly language combines some HL abstraction in the form
of high level conditions and high level looping constructs with the
powers of the S-HLAL. Many people believe HLALs are not capable of
writing low-level code like that from a macro assembly language or a
pure assembly language. This is a lie. All current HLALs can have code
written in low-level form, because if they couldn't, then they couldn't
be assembly programs.
Examples of HLALs are HLA, MASM, TASM, and (what of the language
actually belongs to it) Terse.
5) What "Assembly Language" means in "normal" usage.
This is the section where I repair the damage I've done to your personal
beliefs. I will give you the average personal definition of assembly
language. Before doing so, however, I will have to explain the concept
of the personal definition.
The personal definition is the definition of a word a person uses when
it is used in "normal" context. Personal definitions vary from person
to person, so I can only give you the usual definition as used by most
people.
The normal personal definition of the phrase "assembly language" isn't a
definition at all, but a group. This group consists of assembly
languages, macro assembly languages, S-HLALs, and HLALs. A good number
of people, however, don't include S-HLALs and HLALs in their definition
of assembly language.
6) Conclusion
Like these definitions? I hope so. If not, then you don't have to use
them. I don't honestly care. I'll likely get nailed for this and start
another HLA vs. RosAsm debate, but who knows and who cares? I can only
hope for the best.
(If I don't have a 200 post long flame war next morning, I'll be surprised.)
John Found
>
>This thread is about the catagories of assembly languages.
>It is *NOT* about their implimentations, whatever they may be.
>
The main problem in these type of classifications is that they
are not based on the internal nature of the assemblers but on
personal feelings of the author thus producing absolutely
subjective opinion and causing simply the next flame war.
In this little article I will use following terminology
about compilers:
- Translator - program that provides translation of human
readable code (source text) to the machine executable form.
There are two types of translators:
1. Interpreters - they executes the program in the moment of
translation.
2. Compilers - they translate the program without execution
and (usually) stores the machine executable form for later
translation.
What will be the result if we try more scientific approach?
We can see even on first sight, that every so called assembler,
actually contains at least three _independent_ modules:
1. compile time language interpreter (CTL)
2. native assembly language compiler (ALC)
3. data definition language compiler (DDL)
These modules process the source file separately or simultaneously,
but independenly from each other. In some cases you even can use one
of the modules instead of other to generate the same code.
Let examine every of these modules in details:
1. Compile time language interpreter (CTL) - aka "macro language" -
this is (in known cases)interpreted language usually aimed to modify
the source code before actual assembling. This language is independent
from the assembler and can have any syntax the assembly author prefer.
In most cases, CTL is created to be as simple as possible and in the
same time as powerfull as possible. Also very important is the speed
of executing of this language.
2. native assembly language compiler (ALC) processes only the part of
the code that contains native processor instructions. We have to consider
assembly instructions are those defined in the processor manuals.
Of course the syntax may differs in different assembler, but important
thing is correspondence with the machine language instructions.
For example, assembler may use "op1 = op2" instead of "mov op1, op2".
If we have instruction: "eax = ebx" and assembler translates it to
"8bh, 0c3h" machine instruction, defined for x86 processors as "mov eax,ebx"
everything is ok and this process can be considering as "assembling".
But if assembler allows using "es = ds" and translates it as "1eh, 07h" -
this process is not true assembling, because there is no such instruction
in x86 processors that moves ds to es. There are TWO instructions "push ds"
and "pop es".
So, to make this translation assembler have to make some other than
"assembling" processing on the source code. Usually this processing can
be considering as "preprocessing" - modification of the source text before
actuall translation.
Note that it isn't improtant how actually assembler provides this
translation -
with internal macroses, CTL, special ALC, etc.
3. Data definition language (DDL) - this language is aimed to produce the
binary part of the code that contains data and thus can't be created by the
ALC.
Usually the syntax of the data definition language is consistent to the
syntax of the assembler - statements as "db, dw, dd" etc. actually are
pseudo instructions that have binary opcodes depending of the data they
defines.
Actually, data definition language is processor independent language and
assembler authors have to treat it as such. We can't classify assemblers
by their DDL at all, because DDL have nothing to do with assembly language.
Well, at the end, my definition of the assembler. It is based only on
second
part of assembler - "assembly language compiler" because the CTL and DDL
are processor independent languages and have nothing to do with assembler.
Definition:
If the ALC of the compiler provides true translation of the source code
to the machine instructions without internal interpretation other than
provided by the processor manufacturer, it can be considered as "assembler".
Regards.
NoDot
> The main problem in these type of classifications is that they
> are not based on the internal nature of the assemblers but on
> personal feelings of the author thus producing absolutely
> subjective opinion and causing simply the next flame war.
Which I would have though to start by this time. It's been up for at
least 10 hours, and your the only person who has replied so far.
> Definition:
> If the ALC of the compiler provides true translation of the source code
> to the machine instructions without internal interpretation other than
> provided by the processor manufacturer, it can be considered as "assembler".
However, the CTL of an assembler can do just about anything, correct?
("just about" being key words)
> Regards.
NoDot
John Found
>
>However, the CTL of an assembler can do just about anything, correct?
>("just about" being key words)
What CTL do, is fully under programmer control because it is language and
someone have to write program for it to make something usefull. Also, the
power of CTL differs from assembler to assembler. Actually, there is no
problem to be created assembler, using some small standard interpreted
language (Forth for example) as a CTL.
But the CTL does not turn assembler into high-level or low-level.
Regards
NoDot
> What CTL do, is fully under programmer control because it is language and
> someone have to write program for it to make something usefull. Also, the
> power of CTL differs from assembler to assembler. Actually, there is no
> problem to be created assembler, using some small standard interpreted
> language (Forth for example) as a CTL.
> But the CTL does not turn assembler into high-level or low-level.
How does HLA rate on your classification, then?
> Regards
NoDot
John Found
Well, shortly - for me HLA, in its current stage, is advanced complex
preprocessor with hidden built-in macroses.
If we are talking about whole system - HLA + backend assembler + linker -
it is compiler for a language similar to C-- (I am not talking about syntax
but about features).
Regards.
Randall Hyde
"John Found" <john...@bgdev.org> wrote in message
news:2rlr3gF...@uni-berlin.de...
Except C-- doesn't support machine instructions.
Take away the "built-in macros" and that's what HLA is -- machine
instructions.
Cheers,
Randy Hyde
Randall Hyde
>
> What will be the result if we try more scientific approach?
I do not see the "scientific method" in use below, but okay.
> We can see even on first sight, that every so called assembler,
> actually contains at least three _independent_ modules:
>
> 1. compile time language interpreter (CTL)
> 2. native assembly language compiler (ALC)
> 3. data definition language compiler (DDL)
May as well throw in the linker, too.
>
> 2. native assembly language compiler (ALC) processes only the part of
> the code that contains native processor instructions. We have to consider
> assembly instructions are those defined in the processor manuals.
>
> Of course the syntax may differs in different assembler, but important
> thing is correspondence with the machine language instructions.
>
> For example, assembler may use "op1 = op2" instead of "mov op1, op2".
>
> If we have instruction: "eax = ebx" and assembler translates it to
> "8bh, 0c3h" machine instruction, defined for x86 processors as "mov
eax,ebx"
> everything is ok and this process can be considering as "assembling".
>
> But if assembler allows using "es = ds" and translates it as "1eh, 07h" -
> this process is not true assembling, because there is no such instruction
> in x86 processors that moves ds to es. There are TWO instructions "push
ds"
> and "pop es".
> So, to make this translation assembler have to make some other than
> "assembling" processing on the source code. Usually this processing can
> be considering as "preprocessing" - modification of the source text before
> actuall translation.
> Note that it isn't improtant how actually assembler provides this
> translation -
> with internal macroses, CTL, special ALC, etc.
So the appearance of a *single* item like this, means it is no longer
an assembler, despite the fact that all the other facilities are available?
What is the difference between this and a user-defined macro?
E.g.,
movseg es, ds
???
Like Rene, you're trying to define a product by its lack of capabilities
rather than by its capabilities, and this type of definition always leads
to inconsistencies in the definition.
> Well, at the end, my definition of the assembler. It is based only on
> second
> part of assembler - "assembly language compiler" because the CTL and DDL
> are processor independent languages and have nothing to do with assembler.
> Definition:
> If the ALC of the compiler provides true translation of the source code
> to the machine instructions without internal interpretation other than
> provided by the processor manufacturer, it can be considered as
"assembler".
"Internal translation"?
What does that mean?
Gee, *most* assemblers provide some internal translation. Indeed,
that's the basis of parsing and code generation. Again, trying to define
an assembler based on a *lack* of facilities just leads to ambiguities.
What you really need is "this is what a language must possess to be
called an assembly language." Listing the machine instructions is a good
start.
*Every* attempt I've seen (lately) to define an assembler based on
extra features has been aimed at "showing" HLA not to be an assembler,
clearly such "definitions" are so incredibly biased as to be untrustworthy,
anyway.
Cheers,
Randy Hyde
Dr Jekyll
> rather than by its capabilities, and this type of definition always leads
> ...
> *EVERY* attempt I've seen (lately) to define an assembler based on
> extra features has been aimed at "showing" HLA not to be an assembler,
> clearly such "definitions" are so incredibly biased as to be
>
I quote:
"This is not a thread about HLA.
This is not a thread about RosAsm.
This is not a thread about whether or not HLA is an assembler.
This is not a promotion for *any* product whatsoever."
With all due respect, Mr Hyde, this is completely insane. The very first
lines in the very first post said that this was not about you or Mr Betov.
Now, this thread is lost forever. Sorry if I disappoint you, but I won't
participate in your fights. I think the people who want to understand my
viewpoint already have done so and once I've made myself clear, I'll just
leave it up to everyone to decide for themselves what to believe.
I wish you good luck, Mr Hyde. One day maybe you'll be the king of ALA,
who knows? Just keep arguing and I'm sure you'll "win" in the end.
(sigh...)
Regards,
Dr Jekyll
NoDot
> With all due respect, Mr Hyde, this is completely insane. The very
> first lines in the very first post said that this was not about you or
> Mr Betov. Now, this thread is lost forever. Sorry if I disappoint you,
> but I won't participate in your fights. I think the people who want to
> understand my viewpoint already have done so and once I've made myself
> clear, I'll just leave it up to everyone to decide for themselves what
> to believe.
The fact that a new flame war hasn't started is a surprise. I expected
my notices to be disreguarded and insults flinging every-which way.
> Regards,
> Dr Jekyll
NoDot
John Found
>
>> We can see even on first sight, that every so called assembler,
>> actually contains at least three _independent_ modules:
>>
>> 1. compile time language interpreter (CTL)
>> 2. native assembly language compiler (ALC)
>> 3. data definition language compiler (DDL)
>
>May as well throw in the linker, too.
You are right here - I missed linker, simply because I never use
linkers. :) It is optional component, just as 1 and 3
>So the appearance of a *single* item like this, means it is no longer
>an assembler, despite the fact that all the other facilities are available?
>
>What is the difference between this and a user-defined macro?
>E.g.,
>
>movseg es, ds
>
No, you have to read more carefully - I never said that compiling
mov es, ds will turn the assembler to not-assembeler.
I only wrote that this type of compilations have to be considered
as a part of preprocessing and not a part of assembling.
Also after some thought, I thing that I have to include in the list
one more module:
0. Fixed source processor (FSP) - that is something like CTL, but it is
hard coded in the compiler and is out of user control. For example FASM
uses fixed preprocessing to convert input text source to its internal
intermediate code aimed to provide high compilation speed.
My opinion is that fixed preprocessing MUST not affect generated code
in any way, because that means less control for the user.
So, including this module - HLA can be considered as combination of
modules FSP and CTL.
>Like Rene, you're trying to define a product by its lack of capabilities
>rather than by its capabilities, and this type of definition always leads
>to inconsistencies in the definition.
One product is "what it have" AND "what it have not" - both are important
and using only one of them leads to inconsistencies. I am using both when
I try to define conceptions.
>*Every* attempt I've seen (lately) to define an assembler based on
>extra features has been aimed at "showing" HLA not to be an assembler,
>clearly such "definitions" are so incredibly biased as to be untrustworthy,
Well, my little article was not ( really :) ) aimed to prove anything
about HLA. Actually it was aimed to demostrate that CTL and mainly DDL
are machine independent and have to be considered relatively independent.
That means that authors can use almost any standard interpreted language
for CTL - forth, perl, PHP etc. and freely use HLL DDLs - like pascal one
(IMHO excelent) without harm to the low-level power of their assemblers.
Cheers,
John Found
Randall Hyde
> "Randall Hyde" <rand...@earthlink.net> wrote:
> >
> >> We can see even on first sight, that every so called assembler,
> >> actually contains at least three _independent_ modules:
> >>
> >> 1. compile time language interpreter (CTL)
> >> 2. native assembly language compiler (ALC)
> >> 3. data definition language compiler (DDL)
> >
> >May as well throw in the linker, too.
>
> You are right here - I missed linker, simply because I never use
> linkers. :) It is optional component, just as 1 and 3
So then, while we are throwing in *optional* components -
how about the high-level assembler component?
The fact that you don't use it doesn't mean others don't :-)
>
> >So the appearance of a *single* item like this, means it is no longer
> >an assembler, despite the fact that all the other facilities are
available?
> >
> >What is the difference between this and a user-defined macro?
> >E.g.,
> >
> >movseg es, ds
> >
>
> No, you have to read more carefully - I never said that compiling
> mov es, ds will turn the assembler to not-assembeler.
> I only wrote that this type of compilations have to be considered
> as a part of preprocessing and not a part of assembling.
That's not what "preprocessing" has traditionally meant.
"preprocessing" occurs *before* compilation. Typically,
the preprocessor translates some syntactical form to a *different*
syntactical form that is still syntactically correct *source input*
to the compiler. Take, for example, a statement like HLA's
mov( memsrc, memdest );
that gets translated to
push( memsrc );
pop( memdest );
HLA does not translate this to *source input* text
that can be further processed by the HLA compiler at
some later time. Instead, HLA compiles this statement
directly into the appropriate output code (appropriate, as
defined by the output format).
Preprocessors, by definition, make a separate pass over
the source code *prior* to compilation. They convert
syntactical entities in the preprocessor's language into
the *source input* language. They pass all syntactically
unrecongizable text through (assuming that it's all in the
source language). This is why most macro assemblers'
macro systems are *not* preprocessors - they usually
run concurrently with the assembler, they do not run as
a separate (and earlier) pass. This is also why people's
attempts at characterizing HLA as a preprocessor is
incorrect - if HLA doesn't recognize an input statement,
it reports an error and rejects the attempt at compilation.
While it is certainly possible to process entities such as
"movseg" via a preprocessor, that certainly is *not* the
only way to do it. The assembler can *directly* convert
that statement to the four-byte binary instruction code that
represents the two instructions it compiles into -- in such a
case, characterization as a "proprocessor" is incorrect.
>
> Also after some thought, I thing that I have to include in the list
> one more module:
>
> 0. Fixed source processor (FSP) - that is something like CTL, but it is
> hard coded in the compiler and is out of user control. For example FASM
> uses fixed preprocessing to convert input text source to its internal
> intermediate code aimed to provide high compilation speed.
> My opinion is that fixed preprocessing MUST not affect generated code
> in any way, because that means less control for the user.
>
> So, including this module - HLA can be considered as combination of
> modules FSP and CTL.
Some statements in HLA are processed this way, for sure (like memory
to memory moves), but to try and characterize the HLAPARSE.EXE
program in this manner is a bit incorrect.
Also, your definition fails to consider ambiguity of instruction encoding.
Usually, the encoding of instructions like "mov eax, ebx" is out of the
user's control because the user cannot control which of the (multiple
valid) opcodes the assembler generates.
But by and large, we're left with the "Rene paradox" of "it's okay
if the user writes a macro to do this, but it's not okay for the
assembler implementor to do the same thing." This doesn't make
sense, at all. Either way, the source input is exactly the same
(with the possible exception of an extra macro needing to be
written in the first case). Whether the macro is written by the
user, written by the language designer and included as part of
an include file, or built right into the language proper, it doesn't
really change the status of the product at all.
> One product is "what it have" AND "what it have not" - both are important
> and using only one of them leads to inconsistencies. I am using both when
> I try to define conceptions.
But attempts to date to try and do this have all failed.
Any definition that says "MASM is not an assembler" is not acceptable.
You may personally be happy with such a definition you come up with,
but it will not be acceptable to the general population.
> Well, my little article was not ( really :) ) aimed to prove anything
> about HLA.
Of course not.
> Actually it was aimed to demostrate that CTL and mainly DDL
> are machine independent and have to be considered relatively independent.
> That means that authors can use almost any standard interpreted language
> for CTL - forth, perl, PHP etc. and freely use HLL DDLs - like pascal one
> (IMHO excelent) without harm to the low-level power of their assemblers.
And what happens with they add that *fifth* component of an assembler,
the high-level component? Like the linker and CTL, its use is optional.
Like having the presence of the CTL, its presence does not, in any way,
affect the end user's ability to write low-level assembly code. Like the
CTL, it can be completely ignored. So why the big fuss from people that
adding this *optional* component to an assembler means you don't have
an assembler any more?
Recap:
An assembler consists of:
1. A compile-time language (CTL), which is optional.
2. A data-definition language.
3. A machine instruction language (the NLC)
4. A fixed source processor (what Rene calls "built-in macros"), which is
optional.
5. A high-level statement compiler (optional).
Yes, there is a difference between (4) and (5). (4) is a *fixed*
source processor -- the same input always produces the same
output regardless of context. This isn't true for (5) which can
produce different output based on context.
The presence of (5) is what generally differentiates a
"high-level assembler" from a "traditional assembler".
Note that things like structs and unions appear in (2) and their
presence doesn't really make an assembler "high-level" IMO,
though opinions certainly vary on that matter.
Cheers,
Randy Hyde
Randall Hyde
"NoDot" <no_...@msn.remove_this.com> wrote in message
news:2rm4caF...@uni-berlin.de...
DrJ sez:
"I won't participate in your fight while calling you insane...."
Yeah, right.
NoDot sez:
"(If I don't have a 200 post long flame war next morning, I'll be
surprised.)"
Bait, or what? :-)
Seriously, it's all been said before. Just read:
http://webster.cs.ucr.edu/AsmTools/HLA/HLADoc/HLARef/HLARef2.html#1045084
Cheers,
Randy Hyde
John Found
>Recap:
>
>An assembler consists of:
>
>1. A compile-time language (CTL), which is optional.
>2. A data-definition language.
>3. A machine instruction language (the NLC)
>4. A fixed source processor (what Rene calls "built-in macros"), which is
>optional.
>5. A high-level statement compiler (optional).
>
>Yes, there is a difference between (4) and (5). (4) is a *fixed*
>source processor -- the same input always produces the same
>output regardless of context. This isn't true for (5) which can
>produce different output based on context.
Definately 4 and 5 are equal. I used the word "fixed" maybe wrong -
it means namely "built-in", "hard-coded", "not in user control".
Such processing can be as complex and context dependent as author
decides. For example "FSP" module can provide compilation of Delphi
code to the low-level assembly instructions. So, we will get Delphi
compiler - are you claim Delphi is assembler with some extra features?
So to resume:
1. A compile-time language (CTL)
2. A data-definition language. (DDL)
3. A machine instruction language (NLC)
4. A fixed source processor (FSP)
Important: This structure does not reflect the internal implementation
of particular assembler. This sturcture reflects internal logic of action.
Every of this elements may or may not be implemented as independent module
in the assembler. Also, the numbers does not reflect the order modules
process the source code. For example - in many imlpementations NLC and
DDL are processed by one module. Also, parts of FSP can be executed
together
with CTL and other parts, together with NLC.
Also in my texts "optional" means "optionally existing" not "optional for
using".
>Whether the macro is written by the
>user, written by the language designer and included as part of
>an include file, or built right into the language proper, it doesn't
>really change the status of the product at all.
It does. It is a matter of control Randy. The high level languages take
away this
control from the programmer. That is the reason why some people decided to
use
assembly language.
>
>The presence of (5) is what generally differentiates a
>"high-level assembler" from a "traditional assembler".
>
So, I removed the stage 5 and now I can write it this way:
FSP affecting generated code is a way HLL compilers
act. Presense of such type of FSP move the assembler to the
groups of HLLs. There is some kind of critical mass of
features. Crossing it, the assembler becomes HLL.
For me this critical mass can be defined as: "If the compiler is
able to create working application using only code processed by
FSP, this language have to be considered HLL."
Note that FSP not affecting generated code, ensures that the
assembler never can degenerate to HLL.
Regards.
Percival
Technically NoDot started it with his question "How does HLA stand in
your clasification then"
Then It was mostly defense and argument that HLA isn't a preprocessor
from there on.
It seems as if this "war" is no one's fault. As each answer so far is
logical.
Percival
NoDot
> So to resume:
>
> 1. A compile-time language (CTL)
> 2. A data-definition language. (DDL)
> 3. A machine instruction language (NLC)
> 4. A fixed source processor (FSP)
If you ask me, 1 and 4 should be one part.
> Important: This structure does not reflect the internal implementation
> of particular assembler. This sturcture reflects internal logic of action.
> Every of this elements may or may not be implemented as independent module
> in the assembler. Also, the numbers does not reflect the order modules
> process the source code. For example - in many imlpementations NLC and
> DDL are processed by one module. Also, parts of FSP can be executed
> together
> with CTL and other parts, together with NLC.
Reminds me of the problems arising from the language/implimentation
confusion.
> Also in my texts "optional" means "optionally existing" not "optional for
> using".
It can be both, depending.
>>Whether the macro is written by the
>>user, written by the language designer and included as part of
>>an include file, or built right into the language proper, it doesn't
>>really change the status of the product at all.
>
> It does. It is a matter of control Randy. The high level languages take
> away this
> control from the programmer. That is the reason why some people decided to
> use
> assembly language.
It depends on whether or not teh sequence of machine instructions can be
guessed with accuracy. I know that if I write:
--------------------------------
if(eax > ebx) then;
mov(eax, ebx);
endif;
--------------------------------
That it becomes:
--------------------------------
cmp(eax, ebx);
jng(notTrue);
mov(eax, ebx);
notTrue:
--------------------------------
With the label changing, of course. If the instructions emitted can be
guessed, then there's no reason to not just build them into an
assembler, instead of making macros which will be complicated.
> Regards.
NoDot
Frank Kotler
> It depends on whether or not teh sequence of machine instructions can be
> guessed with accuracy. I know that if I write:
>
> --------------------------------
> if(eax > ebx) then;
> mov(eax, ebx);
> endif;
> --------------------------------
>
> That it becomes:
>
> --------------------------------
> cmp(eax, ebx);
> jng(notTrue);
> mov(eax, ebx);
> notTrue:
> --------------------------------
How do you know it'll be "jng", not "jna"?
Best,
Frank
Percival
Doesn't HLA differentiate between unsigned and signed numbers? (jng if
signed, jna if unsigned)??
Anyway, i discredit the use of that type of code.
Percival
Frank Kotler
>
> Frank Kotler wrote:
> > NoDot wrote:
> >
> >
> >>It depends on whether or not teh sequence of machine instructions can be
> >>guessed with accuracy. I know that if I write:
> >>
> >>--------------------------------
> >>if(eax > ebx) then;
> >> mov(eax, ebx);
> >>endif;
> >>--------------------------------
> >>
> >>That it becomes:
> >>
> >>--------------------------------
> >> cmp(eax, ebx);
> >> jng(notTrue);
> >> mov(eax, ebx);
> >>notTrue:
> >>--------------------------------
> >
> >
> > How do you know it'll be "jng", not "jna"?
> >
> > Best,
> > Frank
>
> Doesn't HLA differentiate between unsigned and signed numbers?
The CPU does, HLA had better!
> (jng if
> signed, jna if unsigned)??
Right, but how do you know which ">" is going to generate? (RTFM, I
suppose... or try it and *look*...)
> Anyway, i discredit the use of that type of code.
Hey, NoDot posted it, not me! :)
I was thinking about this issue when we were talking about "data
typing", and whether it makes sense to have an assembler remember
"types". When it comes to signed/unsigned, well... we could "double
check" to make sure the correct conditional jump was used, *but* we
can't tell for sure (in the "general case") where the flags we're
testing were set. So it's "useless" to try to do this. (if we can't
"always" get it right, we might as well not bother at all, IMO).
When it comes to a "compiler", we need to know, as the compiler must
*provide* the correct instruction. And this is true of the "macro
language" of a macro-assembler. We could, of course, provide a different
macro for signed and unsigned - I assume that's what HLA does - but if
we want "if (answer > 42);" to work for either, we could benefit from
"remembering" whether you declared "answer" to be signed or unsigned. In
the case of two registers, there still needs to be a way to indicate in
the macro whether we want signed or unsigned, so it isn't that big a
deal, but a macro-assembler *could* benefit from this information.
Whereas a symbolic- (not macro-) assembler has no use for it.
This is a potentially "real" dividing line between "types" of
assemblers. I'm not sure that having "dividing lines" is actually very
useful, though. If the result is decent machine code, who cares how it
*got* that way?
Best,
Frank
John Found
>
>John Found wrote:
>> So to resume:
>>
>> 1. A compile-time language (CTL)
>> 2. A data-definition language. (DDL)
>> 3. A machine instruction language (NLC)
>> 4. A fixed source processor (FSP)
>
>If you ask me, 1 and 4 should be one part.
No, they shouldn't. Actually CTL and FSP have similar functions and
action, but there is one important difference that separate them -
user control. CTL is fully under user control while FSP serves only
internal needs of the compiler. FSP may or may not affect generation
of the code.
And at the end - in my analize, namely FSP and its behaviour defines
the border between assemblers and HLLs.
>
>>>Whether the macro is written by the
>>>user, written by the language designer and included as part of
>>>an include file, or built right into the language proper, it doesn't
>>>really change the status of the product at all.
>>
>> It does. It is a matter of control Randy. The high level languages take
>> away this
>> control from the programmer. That is the reason why some people decided to
>> use
>> assembly language.
>
>It depends on whether or not teh sequence of machine instructions can be
>guessed with accuracy. I know that if I write:
>
Yes, you are right here. But this concerns a little bit different topic -
using of complex HLL style constructions in assembly programs.
Unfortunately, when the HLL constructions become more complex and context
dependent, it's harder and even impossible to be guesed what instructions
will be generated by this or that HLL construction.
Also, I am simply not willing to play guessing games with the compiler.
I want it to compile what I am writing. :)
Cheers
Kain
> With the label changing, of course. If the instructions emitted can be
> guessed, then there's no reason to not just build them into an
> assembler, instead of making macros which will be complicated.
>
> > Regards.
>
> NoDot
If it can be done by macros, why bother building it into the
assembler? IMO, if you write a CTL advanced enough to emulate all
types of HLL-isms, it would be far better than having HLL-isms built
in, along with the added benefit of having the most advanced CTL of
any language.
I think the work of Randal and Beth are hitting on such a concept.
Randall Hyde
> "Randall Hyde" <rand...@earthlink.net> wrote:
> >Recap:
> >
> >An assembler consists of:
> >
> >1. A compile-time language (CTL), which is optional.
> >2. A data-definition language.
> >3. A machine instruction language (the NLC)
> >4. A fixed source processor (what Rene calls "built-in macros"), which is
> >optional.
> >5. A high-level statement compiler (optional).
> >
> >Yes, there is a difference between (4) and (5). (4) is a *fixed*
> >source processor -- the same input always produces the same
> >output regardless of context. This isn't true for (5) which can
> >produce different output based on context.
Okay, but I draw a fundamental distinction between a construct
that emits a fixed sequence of instructions (always) versus a
varying code sequence based on context.
Consider the "mov <segreg>, <segreg>" example.
The assembler always emits the same two instructions (push and
pop) with the only variance being the choice of register encodings.
Now consider a statement like
"if ( eax < ebx && f(ecx) || edx >= g(esi)) then ... endif;"
The code sequence you get, including the number of statements
and the statements themselves, varies considerably depending on
the definitions for f, g, and the boolean conjunction and dysjunction
operations (and whether or not the "compiler" treats registers
as unsigned or signed entities).
In the former example, we can define an "opcode" for the
mov <segreg>,<segreg> instruction with two register fields
to be filled in, and *any* assembler could assemble that
code properly (even though the "opcode" is really two distinct
opcode). Nothing like that could be done for an "if" statement.
The difference between these two examples is roughly
equivalent to the difference between regular expressions
and context-free expressions. And that's why I argue that
they're processing is fundamentally different.
As the regular languages are a subset of the context-free
languages, it is certainly the case that your definition for
the FSP will completely subsume all of these examples.
But I argue that it's still a good idea to differentiate these
two cases because an assembler that contains simple
transformations like "mov <segreg>, <segreg>" (and
not much else) is nowhere near as "powerful" as a
a high-level assembler that supports context-free parsing
of statements. From the perspective of the low-level
crowd, you don't want to lump assemblers like FASM
into the high-level assembler category because of the
presence of a few "helper" instructions, and from the
perspective of the high-level assembler user, you want
some sort of differentiation between assemblers that
provide some simple aides and a full-blown high-level
assembler. Otherwise, you get arguments from people that
an assembler is a "high-level" assembler when it is not.
> Definately 4 and 5 are equal. I used the word "fixed" maybe wrong -
> it means namely "built-in", "hard-coded", "not in user control".
> Such processing can be as complex and context dependent as author
> decides. For example "FSP" module can provide compilation of Delphi
> code to the low-level assembly instructions. So, we will get Delphi
> compiler - are you claim Delphi is assembler with some extra features?
Delphi (and in-line assemblers, in general) is a prime example of
what goes wrong when you try to define what is an assembler based
on some syntactical or semantic capabilities of the translator.
The thing that differentiates Delphi (with a decent in-line assembler),
Gas, Visual C++, Borland C++, PowerBasic, and so on, from
assemblers is strictly the focus. These language implementations
were not created for writing assembly language programs. They
were created for writing HLL programs with the ability to drop
down into assembly, as needed.
High-level assemblers, such as MASM, TASM, and HLA,
were created to allow the programmer to write assembly language
programs and jump *up* into HLL code, as needed.
From your "user control" point of view, the difference is important --
the user has complete control over the code a high-level assembler
generates. They can *choose* to write pure low-level code, or
jump up a level or two in abstraction and allow the assembler to
automatically generate some code for them. But *they* always
get that choice. This isn't true in HLLs with in-line assemblers.
>
> So to resume:
>
> 1. A compile-time language (CTL)
> 2. A data-definition language. (DDL)
> 3. A machine instruction language (NLC)
> 4. A fixed source processor (FSP)
>
> Important: This structure does not reflect the internal implementation
> of particular assembler. This sturcture reflects internal logic of action.
> Every of this elements may or may not be implemented as independent module
> in the assembler. Also, the numbers does not reflect the order modules
> process the source code. For example - in many imlpementations NLC and
> DDL are processed by one module. Also, parts of FSP can be executed
> together
> with CTL and other parts, together with NLC.
>
> Also in my texts "optional" means "optionally existing" not "optional for
> using".
Okay.
>
> >Whether the macro is written by the
> >user, written by the language designer and included as part of
> >an include file, or built right into the language proper, it doesn't
> >really change the status of the product at all.
>
> It does. It is a matter of control Randy. The high level languages take
> away this
> control from the programmer. That is the reason why some people decided to
> use
> assembly language.
How does the presence of these facilities take away control from the user?
They exercise the control whether or not they will use them.
If an "assembler" did not allow a user to use instructions like CMP and
Jcc in place of HLL control structures, I'd be in complete agreement.
But every high-level assembler I've seen, that I would consider an
assembler,
does not do this. They have complete control over whether they use the
low-level forms or the high-level forms.
>
> >
> >The presence of (5) is what generally differentiates a
> >"high-level assembler" from a "traditional assembler".
> >
>
> So, I removed the stage 5 and now I can write it this way:
>
> FSP affecting generated code is a way HLL compilers
> act. Presense of such type of FSP move the assembler to the
> groups of HLLs. There is some kind of critical mass of
> features. Crossing it, the assembler becomes HLL.
And I can tell you exactly where that line is --
The moment you can no longer do something in a
"high-level assembler" that can be done in a low-level
assembler, with respect to generating machine instructions
and data, you've crossed that line.
>
> For me this critical mass can be defined as: "If the compiler is
> able to create working application using only code processed by
> FSP, this language have to be considered HLL."
The fault with your definition is that now MASM is a HLL.
And that runs counter to the expectations of the world at large.
>
> Note that FSP not affecting generated code, ensures that the
> assembler never can degenerate to HLL.
"Degenerate" is an interesting use of terms here :-)
You're welcome to your opinion, of course.
But again, it's not something that is commonly accepted by the
vast majority of assembly programmers. Most of them accept
the definition of "If I can do everything that a low-level assembler
does, and I can ignore all the HLL stuff, them I'm writing assembly
language with an assembler."
Cheers,
Randy Hyde
Randall Hyde
"Percival" <dragont...@yahoo.com> wrote in message
news:2rmrg5F...@uni-berlin.de...
Remember, HLA does type checking. And registers, by default,
are unsigned items. Therefore, HLA generates JNA for this
example. If you want JNG, you must explicitly cast EAX or EBX
as follows:
if( (type int32 eax) > ebx ) then...
Cheers,
Randy Hyde
The_Sage
>Date written: Fri, 24 Sep 2004 23:04:20 -0500
>MsgID:<2rk91sF...@uni-berlin.de>
>This thread is about the catagories of assembly languages.
>It is *NOT* about their implimentations, whatever they may be.
>A brief outline so you know what's to come:
>1) Assembly Languages
>2) Macro Assebmly Languages
>3) Semi-High Level Assembly Languages
>4) High Level Assembly Languages
>5) What "Assembly Language" means in "normal" usage.
>6) Conclusion
>1) Assembly Languages
>An Assembly Language (also know as a symbolic assembly language) is a
>lnguages that directly translates down into the processor's instructions
>and includes support for symbolic lables for ease of use,
Assembly language is "a symbolic representation of the machine code of a
specific processor". An assembler converts assembly language into machine code.
That means that the language must be modeled after the actual instruction sets
of the processors they intend to support. These are have always been the
standard definitions and always will be. Anybody who doesn't know this doesn't
know assembly language very well.
>and assembler
>directives, which change depending on the output format and the
>assembler's option level.
>I know of none for the x86 family of processors and runs of any known OS.
Assembler directives are not for the actual assembler, they are for the linker.
>2) Macro Assembly Language
>A Macro Assembly Language is a dirivitive of Assembly Languages. It
>includes the same abilities of assembly languages and also adds
>capabilities such as equates, macros, and symbolic constants. The level
>of power offered by these features is dependant opon the assembler.
>Macro Assembly Languages include (these refer to the languages) NASM,
>and I can't think of any others.
A macro is defined as "a single computer instruction that results in a series of
instructions in machine language". A preprocessor "converts one source language
into another source language". Some people have attempted to try and use macros
to create a psuedo-programming language but the problem is that the macros must
be converted into ASM first before being able to be assembled into machine code,
therefore they are only re-creating a preprocessor, not creating another
language. That also means that macros are not a language...never have been and
never will be. A macro is simply something to save time typing redundant code or
for making code readable.
>3) Semi-High Level Assembly Languages
Let's talk about what "high-level language" means here first. A high-level
language is defined as a "programming language which provides some level of
abstraction above assembly language". That means as soon as you mention
"high-level", you are no longer talking about an assembler. It is sheer
ignorance to talk of "high-level assemblers" as there is no such thing.
And think about this: by your own (inconsistent) definition, C++ is an HLA,
since C++ uses the MASM syntax *and* it has high-level keywords. C++ is far
better than any "HLA" you could ever think of.
>5) What "Assembly Language" means in "normal" usage.
>This is the section where I repair the damage I've done to your personal
>beliefs. I will give you the average personal definition of assembly
>language.
The average personal definition is based on ignorance, not facts -- and I only
believe in facts. So don't worry, you can never damage my personal beliefs as I
only believe in facts, not belief.
Why don't you get a dictionary and see what you've been missing? I will even
give a head start: http://computing-dictionary.thefreedictionary.com/
Please do us all a favor by reading it and then tell all your friends to read
it. Let's end this ignorance once and for all.
The Sage
=============================================================
My Home Page : http://members.cox.net/the.sage
"The men that American people admire most extravagantly are
most daring liars; the men they detest the most violently are
those who try to tell them the truth" -- H. L. Mencken
=============================================================
C
> If it can be done by macros, why bother building it into the
> assembler? IMO, if you write a CTL advanced enough to emulate all
> types of HLL-isms, it would be far better than having HLL-isms built
> in, along with the added benefit of having the most advanced CTL of
> any language.
I agree completely, plus having the HLLisms implemented
via CTL macros gives much greater flexability. The only
disadvantage is that an assembler processing macro HLLisms,
as opposed to inbuilt HLLisms, is likely to take longer.
(This is why Luxasm will implement all HLLisms via macros.)
But having the fastest assembler is nothing compared to
having the assembler with the most powerful semantics.
C
2004-09-26
John Found
>The only
>disadvantage is that an assembler processing macro HLLisms,
>as opposed to inbuilt HLLisms, is likely to take longer.
>(This is why Luxasm will implement all HLLisms via macros.)
>
Visibly, in most cases, the assembler writers doesn't pay
needed attention to carefully design CTL's of its assemblers.
btw: FASM have no any problems with speed, regardless of how
complex macroses the program use. And it becomes faster with
any new version.
>But having the fastest assembler is nothing compared to
>having the assembler with the most powerful semantics.
IMHO, the power have to be "exact" not more, nor less.
The keyword is "balance". :)
Regards.
C
> C <cc-...@hermes.mirlex.com> wrote:
>
>>The only
>>disadvantage is that an assembler processing macro HLLisms,
>>as opposed to inbuilt HLLisms, is likely to take longer.
>>(This is why Luxasm will implement all HLLisms via macros.)
>
> Not at all. This depends of the speed of CTL interpreter.
> Visibly, in most cases, the assembler writers doesn't pay
> needed attention to carefully design CTL's of its assemblers.
Oh, it most certainly will take longer for an assembler to
process HLLisms via macros than it will to do so with an
inbuilt processor -- but, as you say, this difference is not
likly to be 'visable' for most files. (It is visable on
some though, NASM takes >4 minutes to processor one of my
~5000 line modules using complex macros on nearly every line.)
But the additional flexability the macros give the user is
more than paid for despite the performance penalty, no inbuilt
macros can ever have the flexability of a good CTL.
> btw: FASM have no any problems with speed, regardless of how
> complex macroses the program use. And it becomes faster with
> any new version.
There is no doubt that a well designed CTL and fast assembler
will remove many of these problems, Luxasm is to go one step
further and assemble 'as you type', completely eliminating
visable compile time overhead. Therefore implementing HLLisms
via macros has _no_ drawbacks with this design.
>>But having the fastest assembler is nothing compared to
>>having the assembler with the most powerful semantics.
>
> IMHO, the power have to be "exact" not more, nor less.
> The keyword is "balance". :)
Well yes, you want an assembler this is reasonably fast, but
I say that powerful semantics are more important. (Guess I
am loosing clarity by going for sound-bites again.) A well
designed CTL can allow the user to express macros efficiently
which tends to allow them to be processed faster anyway.
Maybe I will play a little with FASM to see what it can do,
there is a Linux version I presume?
C
2004-09-26
John Found
>
>Okay, but I draw a fundamental distinction between a construct
>that emits a fixed sequence of instructions (always) versus a
>varying code sequence based on context.
>
The first case is simply the limit of the second when the context
dependency tend to zero. :)
>Consider the "mov <segreg>, <segreg>" example.
>The assembler always emits the same two instructions (push and
>pop) with the only variance being the choice of register encodings.
Hm, it is not true at all. For example compiler can generate:
mov ax, segreg1
mov segreg2, ax
btw: register trashing in hard-coded HLL statements is (c)MS you know.
..or without register trash:
push eax
mov ax, segreg1
mov segreg2, ax
pop eax
..and you never can know it if it is hard-coded in the
compiler. You have to read this somewhere or have to test it yourself.
While if this construction (mov seg, seg) is created using CTL, the user
can check the logic immediately and even change it if he wants something
different.
>From your "user control" point of view, the difference is important --
>the user has complete control over the code a high-level assembler
>generates. They can *choose* to write pure low-level code, or
>jump up a level or two in abstraction and allow the assembler to
>automatically generate some code for them. But *they* always
>get that choice. This isn't true in HLLs with in-line assemblers.
Randy, you and the HLL-style defenders very often argue that having
both: high and low level in the assembler is good, because
"They can *choose* to use or not these HLL statements."
That is not true at all. They have no choice, because of many reasons.
Did the heroin addicted one have a choice to use or not to use heroin?
Formally *yes*, but not in the real world. Only fear for his life can stop
such man from using heroin. Unfortunately in programming, there is no such
powerful motive.
Very similar is with HLL-isms in the assembly language. People using them
are trained to use them. They are HLL programmers. They think with such
categories. They have no choice at all. They have to be re-educated to
use low-level constructions. At least they have to know equally both
low and high level programming to make some choice - good or bad.
Also, there is the code of the libraries and also other reusable code,
that is written in high-level style (because of above reasons).
If someone want to use others code - he have no choice.
So, I think the argument about "choice" is simply slogan, not someting
real. But you know, if you repead some not exactly true slogan hundreds
times it becomes true. (do you know who said that for the first time?)
>> For me this critical mass can be defined as: "If the compiler is
>> able to create working application using only code processed by
>> FSP, this language have to be considered HLL."
>
>The fault with your definition is that now MASM is a HLL.
>And that runs counter to the expectations of the world at large.
Well, if I have good definition and I can prove it is true. The fact
that MASM becomes HLL can't make me think the definition is wrong.
Look, there is some histeresys near to the border line - like this:
If you are looking from the HLL side - even HLA will seems to be
assembler, but if you are looking from the assembler side - MASM
sometimes looks like HLL. So, from what side of the border you are
looking mr.Hyde? ;)
>> Note that FSP not affecting generated code, ensures that the
>> assembler never can degenerate to HLL.
>
>"Degenerate" is an interesting use of terms here :-)
But exactly reflects my opinion. :) To remind you - I am also
profesional Delphi programmer. You can't claim I have no knowledge
about HLL's.
>You're welcome to your opinion, of course.
>But again, it's not something that is commonly accepted by the
>vast majority of assembly programmers.
It seems there is simply no "vast mojority" of asm programmers. They are
only few. The rest are unfortunately HLL programmers that use inlined
assembly code in its programs and think that is the most proper way.
I will be happy to be wrong here, but if there are assembly programmers,
where are the programs they wrote?
I know only few fully assembly written applications. The most of them are
in developement stage. Also, the most of them are assembly programming
tools.
The rest in "vast majority" is a big heap of demos and tutorials.
Cheers.
Robert Redelmeier
> btw: register trashing in hard-coded HLL statements is
> (c)MS you know. ..or without register trash:
>
> push eax
> mov ax, segreg1
> mov segreg2, ax
> pop eax
But this trashes memory at [esp]
-- Robert
John Found
That was exactly my point. It is never excusable to have
such constructions hard coded in the assembler.
Regards.
Percival
For the heck of it, I'll play devil's advocate.
However, take a good look at Perl. Anyone who has worked with it quickly
understands that it is very possible to write readable code in it. True,
it is generally understood that $_ was the last return value of a <>
command, and that while(<>) is shortcutted into while(<STDIN>) which is
shortcut for while($_ = <STDIN>) However if STDIN has already closed
then <> stands for the filenames that occured after the program and...
By adding too many shortcuts, it can *reduce* readability of the code,
and remove the user from the low level, and give more hidden meanings to
a _beginner_.
So where does this place HLA? It places HLA right where it is, a high
level assembler, higher level than traditional assemblers, but meets the
requirements for an assembler.
Percival
Percival
> There is no doubt that a well designed CTL and fast assembler
> will remove many of these problems, Luxasm is to go one step
> further and assemble 'as you type', completely eliminating
> visable compile time overhead. Therefore implementing HLLisms
> via macros has _no_ drawbacks with this design.
Ah. You seem to miss one minor drawback. You cannot do many things as
you run the assembler. As the assembler is demanding much of the CPU
time, and rarely goes idle, then it will take away time from the other
aps that are running.
Percival
Randall Hyde
"C" <cc-...@hermes.mirlex.com> wrote in message
news:vYF5d.164$UI2...@newsfe6-win.ntli.net...
> >
> > Not at all. This depends of the speed of CTL interpreter.
> > Visibly, in most cases, the assembler writers doesn't pay
> > needed attention to carefully design CTL's of its assemblers.
>
> Oh, it most certainly will take longer for an assembler to
> process HLLisms via macros than it will to do so with an
> inbuilt processor -- but, as you say, this difference is not
> likly to be 'visable' for most files.
Point 1: The CTL is almost always implemented as an interpreter.
Imagine using an assembler written in an interpretive language rather
than a compiled language. There is a one to three orders of magnitude
difference in speed, typically.
> (It is visable on
> some though, NASM takes >4 minutes to processor one of my
> ~5000 line modules using complex macros on nearly every line.)
> But the additional flexability the macros give the user is
> more than paid for despite the performance penalty, no inbuilt
> macros can ever have the flexability of a good CTL.
Point 2: Decent macros to *fully* implement HLL-like control
structures are *very* complex if you don't have any help from the
assembler (such as processing full Boolean expressions).
Point 3: The speed of processing complex macros is almost always
related to the number of statements in the macro rather than the
speed of the interpreter. Case in point: the HLA Standard Library
stdout.put macro. This guy is quite complex -- requiring the processing
of about 600 lines of code *FOR EACH PARAMETER IT PROCESSES*.
Bottom line is that if you use it 1,000 times in a source file, and each
usage
averages 2-3 arguments, you wind up with over a MILLION lines of code
needing to be processed by the assembler/CTL. I don't care how well
written the assembler & CTL happen to be -- such a load will impact the
speed of assembly. OTOH, if your CTL contains some advanced features
to help reduce the number of lines of code needed for such a macro, then
you can speed up assembly considerably. For proof- just try using the
built-in HLA HLL-like control statements some time and compare their
assembly speed against the macro implementations of the same thing
(which still cheat and use the JF and JT pseudo-instructions). Easily
a two orders of magnitude difference. Granted, HLA's macro implementation
in Flex/Bison isn't the best, but the bottom line is that processing 10x
as many statements is going to wind up costing you dearly in assembly
time, and that's true no matter how well the author has implemented the
CTL.
>
> > btw: FASM have no any problems with speed, regardless of how
> > complex macroses the program use. And it becomes faster with
> > any new version.
>
> There is no doubt that a well designed CTL and fast assembler
> will remove many of these problems, Luxasm is to go one step
> further and assemble 'as you type', completely eliminating
> visable compile time overhead. Therefore implementing HLLisms
> via macros has _no_ drawbacks with this design.
What happens when one macro invokes another, you've used the
first macro throughout the source file, and then you edit the first
macro? If the user immediately tries to assemble, you *will* see
an impact.
Nevertheless, a "background, incremental assembly" is a good
idea. Just keep in mind that it makes the implementation of a
decent CTL *very* difficult.
>
> >>But having the fastest assembler is nothing compared to
> >>having the assembler with the most powerful semantics.
> >
> > IMHO, the power have to be "exact" not more, nor less.
> > The keyword is "balance". :)
>
> Well yes, you want an assembler this is reasonably fast, but
> I say that powerful semantics are more important. (Guess I
> am loosing clarity by going for sound-bites again.) A well
> designed CTL can allow the user to express macros efficiently
> which tends to allow them to be processed faster anyway.
I assume you mean "built-in" macros?
Clearly, processing commonly used/desired control structures like
IF, WHILE, etc., within the assembler is going to make a *big*
difference in assembly speed. Furthermore, it gives you the option
of providing optimizations later on, which are difficult, if not downright
impossible, when using macros to implement those control structures.
Finally, I would point out that *every* macro implementation of
HLL-like control structures I've seen has been really weak.
You don't get to use arbitrary Boolean expressions; most of the
time you can only supply the operands that are legal for a CMP
statement. Decent high-level assemblers go *way* beyond this,
providing conjunction, disjunction, and negation of complex
Boolean expressions. While it is theoretically possible to do this
with a *very good* macro system, the only assemblers I know of
that have a sufficiently powerful macro subsystem to do this
already implement HLL-like control structures in the assembly
language.
>
> Maybe I will play a little with FASM to see what it can do,
> there is a Linux version I presume?
Yep.
Cheers,
Randy Hyde
Randall Hyde
>
> Hm, it is not true at all. For example compiler can generate:
>
> mov ax, segreg1
> mov segreg2, ax
>
> btw: register trashing in hard-coded HLL statements is (c)MS you know.
>
> ..or without register trash:
>
> push eax
> mov ax, segreg1
> mov segreg2, ax
> pop eax
>
> ..and you never can know it if it is hard-coded in the
> compiler. You have to read this somewhere or have to test it yourself.
Well, I'm a big fan of not having the assembler trash register values if
at all possible. (HLA, for example, only "trashes" registers when making
object invocations or when entering a procedure and setting up the
activation record [it does the standard thing of pushing EBP and setting
EBP to ESP's value, though this can be disabled]). For something like
memory-to-memory moves or seg to seg moves, I'd be just as concerned
as you are if the assembler decided to trash the registers behind your back
without any indication of having done so.
MASM, AFAIK, only trashes registers when you pass an address as
a parameter to a subroutine call (and it always uses EAX for that
purpose), and when you enter a procedure it sets up EBP the same
way HLA does (and, again, this can be disabled).
In the same situation (passing parameters by reference), HLA generates
a wide variety of different code sequences in order to preserve all
register values (unless the user has given explicit permission to trash a
register).
BTW, if you can think of a way to call an OO method without
trashing a register and without using a ton of code to do so, let me know
and HLA will switch to that mechanism :-)
>
> While if this construction (mov seg, seg) is created using CTL, the user
> can check the logic immediately and even change it if he wants something
> different.
The user can *still* create their own macro if they don't like the version
the compiler emits. Ditto for all the other HLL-like control structures.
Again, they are not *required* to use those statements. Now, I don't
know about TASM, but I do know that it's pretty easy to look at the
output that HLA and MASM produce for these statements; really not
any more work than simply looking at the include file containing the macro
definitions and imagining how they'd expand in a particular instance.
So I don't believe that the fact that these are built into HLA and MASM
put up any roadblocks to the user's ability to "check the logic".
>
> >From your "user control" point of view, the difference is important --
> >the user has complete control over the code a high-level assembler
> >generates. They can *choose* to write pure low-level code, or
> >jump up a level or two in abstraction and allow the assembler to
> >automatically generate some code for them. But *they* always
> >get that choice. This isn't true in HLLs with in-line assemblers.
>
> Randy, you and the HLL-style defenders very often argue that having
> both: high and low level in the assembler is good, because
> "They can *choose* to use or not these HLL statements."
> That is not true at all. They have no choice, because of many reasons.
> Did the heroin addicted one have a choice to use or not to use heroin?
> Formally *yes*, but not in the real world. Only fear for his life can stop
> such man from using heroin. Unfortunately in programming, there is no such
> powerful motive.
Uh....
the motive is why they bothered to learn assembly in the first place.
If they are going to do nothing but write "HLL programs with MOV
statements", then they're not achieving much by using a high-level
assembler.
The fact that someone *can* abuse a high-level assembler in no
way suggests that everyone does and that there aren't any benefits
to doing so.
And besides, those same users can abuse macros the exact same
way. Take a look at the RosAsm source code sometime if you don't
believe me :-)
> Very similar is with HLL-isms in the assembly language. People using them
> are trained to use them. They are HLL programmers. They think with such
> categories. They have no choice at all. They have to be re-educated to
> use low-level constructions. At least they have to know equally both
> low and high level programming to make some choice - good or bad.
> Also, there is the code of the libraries and also other reusable code,
> that is written in high-level style (because of above reasons).
> If someone want to use others code - he have no choice.
IOW, no choice at all is better than having a plethora of choices.
I like your logic. :-)
>
> So, I think the argument about "choice" is simply slogan, not someting
> real. But you know, if you repead some not exactly true slogan hundreds
> times it becomes true. (do you know who said that for the first time?)
:-)
As I said, no choice at all is better, right? :-)
> >
> >The fault with your definition is that now MASM is a HLL.
> >And that runs counter to the expectations of the world at large.
>
> Well, if I have good definition and I can prove it is true.
It's an opinion, not a fact.
I've got a definition. You've got a definition. And just about
everyone else has a definition. Problem is, most people don't
seem to agree with your definition.
> The fact
> that MASM becomes HLL can't make me think the definition is wrong.
The fact that MASM is accepted as an assembler by just about
everyone except a few individuals out on the fringe is good enough
for me.
> Look, there is some histeresys near to the border line - like this:
> If you are looking from the HLL side - even HLA will seems to be
> assembler, but if you are looking from the assembler side - MASM
> sometimes looks like HLL. So, from what side of the border you are
> looking mr.Hyde? ;)
I'm looking at it from the implementation of an assembler.
HLA maps assembly statements to machine instructions.
It is a translator that converts an assembly language source file
to an executable file. That's good enough for me.
>
> It seems there is simply no "vast mojority" of asm programmers. They are
> only few. The rest are unfortunately HLL programmers that use inlined
> assembly code in its programs and think that is the most proper way.
Arrogance.
Like Rene, if someone doesn't program the same way you do, then they
are not an "assembly programmer." You are the only true way.
Don't expect a lot of people to buy into that idea.
> I will be happy to be wrong here, but if there are assembly programmers,
> where are the programs they wrote?
> I know only few fully assembly written applications. The most of them are
> in developement stage. Also, the most of them are assembly programming
> tools.
> The rest in "vast majority" is a big heap of demos and tutorials.
Assembly programming became dormant through the 1990's. As you're
probably aware, it almost died off during that time. Only during the
past five to seven years has interest in assembly rekindled, and most
of that interest has been from hackers, high-school students, and others
who are notorious for jumping into a project and fading quickly.
Give it time. As those programmers become more experienced
(particularly in writing full apps in OSes like Win32 and Linux),
you'll start to see more apps and non-assembly based tools.
But these things take time. Despite Rene's expectations to the
contrary, experienced programmers aren't about to "jump ship"
from their HLLs en-masse and switch to using assembly code.
Those who grew up with HLLs in the 1990s are going to
continue to use them. The new crop of assembly applications
will begin to appear once today's students mature in their
field and gain enough experience to write full applications.
Until then, full apps that are not assembly development tools
are going to be few and far inbetween.
And if you think that forcing today's programmers to use
low-level coding, even when that isn't necessary, is going
to increase the rate of application development, then I'm afraid
that you're just as mistaken as Rene is with his concept of the
"assembly rebirth".
Cheers,
Randy Hyde
C
> "C" <cc-...@hermes.mirlex.com> wrote in message
> news:vYF5d.164$UI2...@newsfe6-win.ntli.net...
>
>>>Not at all. This depends of the speed of CTL interpreter.
>>>Visibly, in most cases, the assembler writers doesn't pay
>>>needed attention to carefully design CTL's of its assemblers.
>>
>>Oh, it most certainly will take longer for an assembler to
>>process HLLisms via macros than it will to do so with an
>>inbuilt processor -- but, as you say, this difference is not
>>likly to be 'visable' for most files.
>
> Point 1: The CTL is almost always implemented as an interpreter.
> Imagine using an assembler written in an interpretive language rather
> than a compiled language. There is a one to three orders of magnitude
> difference in speed, typically.
My point exactly, it will take longer -- but only in files which
make heavy use of macros.
>>(It is visable on
>>some though, NASM takes >4 minutes to processor one of my
>>~5000 line modules using complex macros on nearly every line.)
>>But the additional flexability the macros give the user is
>>more than paid for despite the performance penalty, no inbuilt
>>macros can ever have the flexability of a good CTL.
>
> Point 2: Decent macros to *fully* implement HLL-like control
> structures are *very* complex if you don't have any help from the
> assembler (such as processing full Boolean expressions).
[I know the 'if' statement in my macro library takes over 300 lines,
though it does have limited support for boolean conjunctions and
dysjunctions.]
> Point 3: The speed of processing complex macros is almost always
> related to the number of statements in the macro rather than the
> speed of the interpreter.
This was not the point I was making, the point I was making was
that a poorly designed CTL forces anyone implementing HLLisms in
that CTL to constantly jump though hoops and restrict the design
to achieve what they want. While a CTL which is well designed
makes writing HLLisms easy, therefore such a CTL would take fewer
lines to implement such functions and would hence take less time
to process each macro. Ie. if the CTL is not sufficiently powerful,
it will be less efficient.
[snip]
>>There is no doubt that a well designed CTL and fast assembler
>>will remove many of these problems, Luxasm is to go one step
>>further and assemble 'as you type', completely eliminating
>>visable compile time overhead. Therefore implementing HLLisms
>>via macros has _no_ drawbacks with this design.
>
> What happens when one macro invokes another, you've used the
> first macro throughout the source file, and then you edit the first
> macro? If the user immediately tries to assemble, you *will* see
> an impact.
Yes, but you must agree that this is not going to be a normal
case, only a rare occurance. Even then modifying something
like a 'jt' or 'jf' macro is likely to only add a second or
two as the whole file does not need to be reprocessed. [The
'jt' and 'jf' macros are used to implement all the conditional
constructs, therefore this is where the largest cascade is
likely to occur.]
[snip]
>>Well yes, you want an assembler this is reasonably fast, but
>>I say that powerful semantics are more important. (Guess I
>>am loosing clarity by going for sound-bites again.) A well
>>designed CTL can allow the user to express macros efficiently
>>which tends to allow them to be processed faster anyway.
>
> I assume you mean "built-in" macros?
Nope. I was remaking my earlier point: an inadequate CTL will
result in inefficient and unnecessarily long macros, which
will take longer to process.
> Clearly, processing commonly used/desired control structures like
> IF, WHILE, etc., within the assembler is going to make a *big*
> difference in assembly speed. Furthermore, it gives you the option
> of providing optimizations later on, which are difficult, if not downright
> impossible, when using macros to implement those control structures.
Optimisations like instruction reordering? I do not believe that
such optimisations are approprate in assembly.
> Finally, I would point out that *every* macro implementation of
> HLL-like control structures I've seen has been really weak.
Yes, that is my main reason for working on Luxasm -- I have found
every CTL lacking (though NASM got pretty near what I want) and
want to write a CTL which will allow me to express the constructs
I want. Getting NASM to support limited boolean expressions is
a real pain -- arbitary expresssion where not worth the hastle,
espectially as the syntax is inefficient. Luxasm is designed
correct these deficiencies, allowing full boolean expressions
to be written relatively easily.
[snip]
C
2004-09-27
Randall Hyde
>
> > Point 3: The speed of processing complex macros is almost always
> > related to the number of statements in the macro rather than the
> > speed of the interpreter.
>
> This was not the point I was making, the point I was making was
> that a poorly designed CTL forces anyone implementing HLLisms in
> that CTL to constantly jump though hoops and restrict the design
> to achieve what they want. While a CTL which is well designed
> makes writing HLLisms easy, therefore such a CTL would take fewer
> lines to implement such functions and would hence take less time
> to process each macro. Ie. if the CTL is not sufficiently powerful,
> it will be less efficient.
Of course.
For example, HLA provides two "pseudo-instructions" JT and JF
that use the following syntax:
JT( BooleanExpression) label;
With these constructs, you can create macros like
#macro _if( expr ):falseLbl;
jf( expr ) falseLbl;
#terminator _endif;
falseLbl:
#endmacro
A fairly simple affair, something that the assembler can
process rapidly. BUT, this simplicity comes at the cost
of including JT and JF in the instruction set (one of John's
FSP objects). Without JT and JF, as you've pointed out,
the macro that would handle complex boolean expressions
(like those that HLA supports) would take hundreds, if not
thousands, of lines.
Given the number of IF statements/macro invocations
found in typical assembly programs today, that would
be *very* expensive.
>
> >>Well yes, you want an assembler this is reasonably fast, but
> >>I say that powerful semantics are more important. (Guess I
> >>am loosing clarity by going for sound-bites again.) A well
> >>designed CTL can allow the user to express macros efficiently
> >>which tends to allow them to be processed faster anyway.
> >
> > I assume you mean "built-in" macros?
>
> Nope. I was remaking my earlier point: an inadequate CTL will
> result in inefficient and unnecessarily long macros, which
> will take longer to process.
Okay, I agree with that 100%.
>
> > Clearly, processing commonly used/desired control structures like
> > IF, WHILE, etc., within the assembler is going to make a *big*
> > difference in assembly speed. Furthermore, it gives you the option
> > of providing optimizations later on, which are difficult, if not
downright
> > impossible, when using macros to implement those control structures.
>
> Optimisations like instruction reordering? I do not believe that
> such optimisations are approprate in assembly.
Well, instruction reordering is one possbility, and whether or not
*you* think it is appropriate, some of your future users may.
It's not appropriate to *always* do this, indeed, I'd argue that it's
only appropriate if the user explicitly requests it, but having that
feature would be pretty cool. Nevertheless, that's not what I'm
talking about. Consider the following HLL-like sequence:
if( expr1 ) then
if( expr2 ) then
<<stmts>>
else
<<stmts>>
endif
// end of nested IF.
else
<<stmts>>
endif
A typical macro expansion of this code will produce
a negative conditional jump from the second IF in the
sequence above to the point "// end of nested IF".
Which, in term, compiles into a jump to the second endif above.
IOW, you've got a jump to a jump. It would be better to simply
have the compiler recognize this situation and emit a jump directly
to the end of the above code sequence. MASM, for example,
does exactly this.
Now I'm not claiming that optimizations like this are impossible
with a decently designed CTL, but you will wind up with some
complex macros that will slow down the processing of HLL-like
statements in the assembly code. But incorporating common
HLL-like statements into the assembler itself, you can easily
add optimizations to these HLL-like statements *WITHOUT
AFFECTING THE NON-HLL-LIKE STATEMENTS*.
Of course, you can always add in a generic optimizer that
makes a separate pass over the entire output code, but that
would "optimize" hand-written assembly code, and most
people don't want that unless they've given explicit permission
to do so. For HLL-like statements, however, not only is the
implicit optimization okay, most people would expect it once
they figure out that is possible to do so (sort of like people
how expect the assembler to do automatic branch displacement
optimizations).
> > Finally, I would point out that *every* macro implementation of
> > HLL-like control structures I've seen has been really weak.
>
> Yes, that is my main reason for working on Luxasm -- I have found
> every CTL lacking (though NASM got pretty near what I want) and
> want to write a CTL which will allow me to express the constructs
> I want. Getting NASM to support limited boolean expressions is
> a real pain -- arbitary expresssion where not worth the hastle,
> espectially as the syntax is inefficient. Luxasm is designed
> correct these deficiencies, allowing full boolean expressions
> to be written relatively easily.
Yep, good Boolean expressions, that don't tweak any registers
and use short-circuit evaluation, can be challenging. Been there,
done that :-)
Cheers,
Randy Hyde
John Found
>[I know the 'if' statement in my macro library takes over 300 lines,
>though it does have limited support for boolean conjunctions and
>dysjunctions.]
IMO, using "if then else" macroses (of hard coded HLL constructions)
is one of the most vicious practices in assembly programming. (maybe
only arithmetic expressions compilers are worse.)
So, from my point of view CTL that make creating of such constructions
harder is rather good than bad. ;)
Regards.
Randall Hyde
The problem, John, is that as a tool's author you want to provide a tool
that lets the end users do whatever they want, not make it hard for
them to achieve their goals. The fact that a CTL makes it easier for
someone else to more easily create HLL constructions in an assembler
has almost *zero* impact on your use of the tool. So a good tool designer
will provide the facilities to allow those other users to use the tool the
way *they* want to while allowing you to use the tool the way *you*
want to. A *poorly designed* tool would force other users to use
the tool the way *you* want to rather than the way *they* want to.
You might argue that creating a tool that forces a certain programming
style is a good thing -- because it makes people write more consistent
(and therefore, easier to read code). However, history certainly indicates
that languages with *fewer* options tend to have the lower-quality
source files.
Again, as long as you can do what *you* want to do with an assembler,
why do you care if someone else can do something you'd rather *not*
do with it? All you're saying is that you think that the world ought to
take on the same view of assembly programming as you do, and that's
just not going to happen (there are too many disparate views of assembly
for this ever to occur). If you want a tool to achieve a reasonable amount
of success, you need to create that tool in such a manner as to satisfy a
large percentage of the population. Despite your disgust with HLL-like
control structures, this *is* something a large percentage of today's
assembly programmers want to see in an assembler. The only reason
I could see you giving for discouraging the promotion of such features
in an assembler like LuxAsm is so that such assemblers don't have
an advantage over the product you happen to use (FASM). But the
bottom line is that we've already got FASM, we don't need a FASM
clone. In order for a new product like LuxAsm to be successful, it
needs to offer some things that FASM does not. HLL-like constructs
(or the ability to easily create them) is one of these attributes.
If the presence of such features annoys you or someone else, even if
you (or they) never plan to use them, well, you can always stick with
FASM.
Cheers,
Randy Hyde
John Found
>.................
AFAIR, In my post I wrote:
"IMO" (in my opinion), "from my point of view" and ";)".
Also, one quick question: If using HLL constructions is the
right (or even acceptable) way of assembly programming, why not to
use C++ with inline assembly??? Contemporary HLL compilers are
pretty good, you know?
Regards.
Randall Hyde
> "Randall Hyde" <rand...@earthlink.net> wrote:
> >.................
>
> AFAIR, In my post I wrote:
> "IMO" (in my opinion), "from my point of view" and ";)"
I don't believe I assumed otherwise.
Indeed, my only argument with your's is that your opinion
is a minority opinion and tools authors need to satisfy the
majority opinion.
>
> Also, one quick question: If using HLL constructions is the
> right (or even acceptable) way of assembly programming, why not to
> use C++ with inline assembly??? Contemporary HLL compilers are
> pretty good, you know?
Nothing wrong with that, when appropriate.
There is a difference between HLL+in-line assembly and a high-level
assembler, however. In-line assembly is fine when you need to drop
down into assembly for a few machine instructions here and there.
High-level assembly is great when most of your work requires
pure assembly, but there are a few sections of code (e.g., initialization)
where neither space nor speed are important and readability is more
important. Again, it's nice to have the choice rather than being
straight-jacketed in this regard. Someone who refuses to use HLLism
can *still* use a high-level assembler the way that they want to, while
someone who *wants* to use HLLisms cannot use an assembler like
NASM or FASM the way they want to. High-level assemblers are
more flexible in this regard.
Cheers,
Randy Hyde
John Found
>Someone who refuses to use HLLism
>can *still* use a high-level assembler the way that they want to, while
>someone who *wants* to use HLLisms cannot use an assembler like
>NASM or FASM the way they want to. High-level assemblers are
>more flexible in this regard.
Well, why someone that refuses to use HLLisms will stay with HLA?
IMHO, that would be very strange person... :D
Do you know such man? I am curious to read some of his sources.
Also, in my observations - those that wants to use HLLisms, already uses
C++ and Delphi.
Regards
Beth
And much of the issue of "assemble speed" is partially nullified (if not
completely nullified) by using incremental assembly (only assemble changes
to the source) and "type time" assembly (run assembler concurrently with
editor to immediately process source code changes as they happen)...
Note, though, that there is no "magic" in that...it's all just a big
"optical illusion"...the actual processing of "HLLism macros" is NOT
actually any faster to process under "incremental" or "type time"
assembly...the trick is strictly processing it _ONCE ONLY_ (incremental)
and to process it concurrently with user editing (type time) so that,
basically, the assembling "overlaps" with the source code editing...
Nevertheless, it _may_ still take longer to process fully externalised (NOT
"built-in") HLLism macros - though I personally think the vast difference
"incremental" and "type time" can make is commonly
_underestimated_...remember, it does it _ONCE ONLY_ and it does that _WHILE
YOU'RE TYPING IT_ (and regards the "cascading" issue...well, we _KNOW_
ahead of time that it's going to "cascade" so _build your data structures
accordingly_...if you know it's "subject to change" then why _fix_ an
address prematurely? Leave it _symbolic_ until the very last moment is the
simple concept Rene failed to consider ;) - but, if it were to take longer,
it would not take an amazing amount longer and the power and flexibility
would, simply, be worth the wait...
The approach, in fact, that I'm taking is to basically create "leg room"
_elsewhere_ in which that extra processing can happen...exploit
concurrency, exploit all that extra RAM and disk sapce we've got these days
to make the process "incremental" (process just the changes to an
intermediate "current state"...coincidentally enough, we have _object code_
which is just such an "intermediate form" by which to make
comparisons...how appropriate current object code formats actually are to
this is another matter...but, if all else fails, there's the options of
simply using "comment" sections to add on additional information...or,
well, simply devising your own object code format appropriate to the
incremental process...if, though, something like ELF and PE can handle it
currently, that's the best for "compatibility"...but, again, a lack of
"compatibility" - just like a lack of "assemble speed" with external
"HLLisms" - is not sufficient to put me off, anyway ;)...
Also, the _methodology_ brings "feedback" to the user whilst editing...this
is a subtle "secondary" benefit but it has an important effect here too
(besides helping to diagnose bugs as soon as possible, when they cost the
least to fix...a "preventative" rather than "curative" approach to
bugs...simply, never code the things in the first place and it costs
_nothing_ to "fix" the bugs because, well, you have no bugs that need
fixing ;)...it's simple, really..._overall development_ is faster and
"seamless" because of the new style of methodology (incremental,
concurrent, feedback, etc.)...you do NOT waste time assembling files with
syntax errors in them - the concurrent assembly and "feedback" process
highlights them the instant you type them - and you do NOT waste time
assembling files with "unresolved externals" (because, again, "feedback"
has introduced Frank's "dots in the corner of the screen" feedback device
which has a display that specifically keeps track of this for you :)...and
so on and so forth...
In fact, as this is "type time" assembling, you do not waste time waiting
for _ANYTHING_...it happens automatically and concurrently with you're
editing...even with complex macros, due to "incremental" assembly, the
assembler need only keep up with you typing...even the fastest human typer
is going to have to work incredibly hard to give a typical 1GHz machine
problems keeping up...even if you could manage to do so, the assembler will
eventually "cascade" the significances of your editing throughout the
source files...at some point, the human is going to stop and the machine
will then catch up...if you suffer any delays at all, then these delays
will be a few seconds at their very, very worst (delibrate "artificial"
source file designed only to give the process problems where one change
"cascades" throughout the entire file ;)...I'm not aware that any
programmer actually types continuously at 10000wpm with highly
interdependent "cascading" code for, ooh, six months without rest...and if
they do, the second they stop typing, the assembler catches up in a matter
of seconds...as with any similar concurrent style like this then it can be
"optimised" to simply "cancel" any processing that is invalidated by more
editing...
If implemented properly, optimised properly and fully exploited, then there
really is no reason to get any kind of noticeable delay whatsoever...it's
_only_ assembling what you're typing as you type it (and _once_ only)...a
human versus a machine on that score? Well, feel free to try to find
"flaws" with artificial source files and typing as fast as is humanly
possible for hours on end...but it'll keep up...rare occasions only will
generate delays due to a lot of "cascading" and, in such cases, it'll be
seconds only...after all, if Rene's RosAsm can process 2MB of source code
in 5 seconds, processing the entire thing from scratch, then the _worst_
this "incremental" approach could ever be faced with is, well, _matching
that_...you know, the "worst case" is somehow a change which invalidates
every single line in the source code and forces it all to be
processed...okay, fair enough...now it's only doing _what every other
non-incremental assembler does every single time by default_...it'll be
fractionally slower than RosAsm by, say, a second or two in an occasion
that, simply, will very, very rarely actually happen (realistically, this
situation would only happen if assembling someone else's large source code
from scratch without being supplied any "intermediate" files...in other
words, re-compiling the Linux kernel straight from a download that only
supplies source code and no "intermediate" files or something like that)...
Ooh, big deal...if someone struggles hard to show that in a specific, rare,
bizarre set of conditions some assembler is all of 50 milliseconds faster
processing things than LuxAsm (when LuxAsm is finally fully equipped with
all these features, that is, of course...the current development version of
LuxAsm is NOT such a tool as yet...but just the basic assembler tool with
which we're going to write the more complex versions of LuxAsm later...you
know, "self-hosting" or "autocompiling" and all that funky jazz :)...then,
fine, you can win the "award"...I'll make a little trophy for you to show
off to people who visit you that you have the "fastest assembler in really
bizarre conditions that never actually happen in reality"...for 99.99% of
all other situations encountered, LuxAsm will have the "instant assembly"
award...you can keep that other award, as I wasn't competiting for it,
anyway ;)...
Indeed, I'm far more radical than my LuxAsm compatriot, C (the person), is
on the matter...we agree that it makes most sense to "externalise" the
HLLisms...but I go further: I'd even be tempted to even "externalise" the
_INSTRUCTION SET_ itself...
I mean, if you've got a CTL that's powerful enough to handle "if" and
"while" and some strange C++ operator syntax and what-not, then it'll be
powerful enough to process machine instruction macros too (especially,
when, of course, you _delibrately design_ it to be able to handle such
things nice and easily ;)...you know, call a macro "mov" and it accepts two
parameters...dump out the appropriate "db" statement according to those
parameters (or an "#error" if the parameters are invalid ;) for the
corresponding machine opcode...
Repeat for entire instruction set and place into a "standard" include file
that comes with the assembler itself...
Prefer AT&T syntax? Fine, create an include file where the macros have AT&T
names "movl" and process AT&T style parameters ("%eax" ;)...then you can
choose Intel or AT&T style by selecting one or the other include file
(provided with the assembler...all you need to do is add some "#include
'Intel.ins'" or "#include 'ATT.ins'" preprocessor statement at the top of
the source file)...
Intel brings out the Pentium 27 and it has new instructions? Fine, just
edit the include file to include the new instructions...or, better yet,
someone on the LuxAsm team does it (or one of the LuxAsm users who's bought
one of these P27s to be able to test out the new macros and "contributes"
it to the LuxAsm project while I'm still saving my pennies ;) and then it
gets included in LuxAsm downloads from then on (and some "update!!" link on
the website just to pick up the new file...download the include file, drop
it in the right "include" directory and, hey presto, Pentium 27
instructions! ;)...
It's all "externalised" so if you never did like some part of "Intel
syntax" then open up the include file and modify it to your liking...or
just take a look into the file, perhaps, to find out what the opcode for
that instruction actually is...they are in external files...now, you can
use these completely as "black boxes" and simply "#include" the standard
file provided and code away...or, if you like "tweaking" and "tinkering"
then you can open the file into the editor and play around to your heart's
content (though, I would recommend making a copy of the files before
proceeding or you'll have to be grabbing them back out of your
LuxAsm.tar.gz download file all the time if and when you make a mess of
things and need to go back to the originals ;)...
LuxAsm users can then, of course, "trade" their HLLism macros...someone's
written a groovy little "switch" macro? Excellent...send it to the LuxAsm
team and we'll happily place it in the "user demos" section or
whatever..."open source" very much is at the heart of this project, after
all...
There's also the radical possibility of an include file that, say, takes
Herbert's Motorola-style syntax and processes that...or, go one further,
you could even have an include file that "emulates" a different
processor...that is, you write 68K code and the macros process this into
equivalent x86 code...this, of course, is a "highly advanced" use...more a
demonstration of the "flexibility" that's potentially there...I doubt
anyone would actually be bothered to go so far as to create
"cross-assembling" instruction set include files, even if only for
"academic exercise"...
And then you could even decide to not bother with "machine instructions"
directly at all...you could create macros that implement some Pascal or
BASIC-like high-level language...
And it's at this point we reach what I've been talking about before...the
objective: a "multi-level language"...note that with the instruction set
"externalised", the tool has now just because _solely_ a (highly powerful
and flexible) CTL...the tool is then able to process anything from "db"
opcodes right up to C++ OOP...every part is accessible...and, generally,
the "multi-level language" is built up delibrately from the "db" opcodes
through machine instructions to "HLLisms" into a complete HLL and maybe
even a VHLL or whatever you like...one set of "building blocks" being used
to build the next layer above...
If you think HLA confuses people with "is it assembler?" then this is
nothing compared to this "multi-level language" concept...indeed, is it
even a programming language, let alone an assembler or compiler? I mean,
it's _soely_ a CTL...so, is it an assembler? Simply, no, it isn't...it
_incorporates_ - when you include the correct macro file - a fully featured
assembler (and I would personally probably implement something
NASM-like...another include file again can encapsulate the "HLLisms" for
those that want them ;)...
And my entire "unified model" objective is satisfied...from "DB" to
literate programming, the entire thing from top to bottom is _unified_...in
syntax, in capabilities, in application, etc....the divide ceases to
be...the "war" will finally be over once and for all:
"I believe it is our...fate...to be here
It is our...destiny...
I believe that this night holds -
For each and every one of us -
The very meaning of our lives...
This IS a war...
And we ARE soldiers...
Death can come for us...
At any time...
In any place...
What if, tomorrow, that war could be over?
Isn't that worth fighting for?
Isn't that worth dying for?
There is only ONE way to save our city..."
[ Morpheus, from the Matrix ]
"Neo" means "new"...it is an anagram of "one"..."unification" is the
process of making things "as one"...the war is over when everyone stops
fighting...when the left hand stops attacking the right hand...when it
stops cutting off the nose just to spite the face..."believe it"...
Assembly language is dead! Long live assembly language! ;)
Beth :)
Kain
>
> Of course.
> For example, HLA provides two "pseudo-instructions" JT and JF
> that use the following syntax:
>
> JT( BooleanExpression) label;
>
> With these constructs, you can create macros like
>
> #macro _if( expr ):falseLbl;
>
> jf( expr ) falseLbl;
>
> #terminator _endif;
>
> falseLbl:
>
> #endmacro
>
>
> A fairly simple affair, something that the assembler can
> process rapidly. BUT, this simplicity comes at the cost
> of including JT and JF in the instruction set (one of John's
> FSP objects). Without JT and JF, as you've pointed out,
> the macro that would handle complex boolean expressions
> (like those that HLA supports) would take hundreds, if not
> thousands, of lines.
>
> Given the number of IF statements/macro invocations
> found in typical assembly programs today, that would
> be *very* expensive.
>
What's the harm in having the functionality to process boolean (and
arithmatic, etc.) expressions as a part of the CTL? The idea is to
have a CTL powerful enough to emulate just about any kind of coding
practice while making it simple to do so.
Randall Hyde
"Kain" <kahl...@yahoo.com> wrote in message
>
> What's the harm in having the functionality to process boolean (and
> arithmatic, etc.) expressions as a part of the CTL? The idea is to
> have a CTL powerful enough to emulate just about any kind of coding
> practice while making it simple to do so.
In computer science, there is a maxim: "optimize for the common case."
That's why you have the compiler handle the statements people use all
the time and provide facilities (like JT and JF) to handle the special cases
that don't come up all the time.
I don't count JT and JF and "functionality to process boolean expressions
in the CTL." These are run-time statements, not CTL. To me, providing
this functionality in the CTL means providing the ability to parse boolean
expressions and emit appropriate code. This is a relatively complex task
(at least, compared to most macros or CTL programs you'd write) and
will take quite a bit of time if you use that facility often (as often, for
example,
as HLL-like control statements get used).
Remember way back when, when I first did the "assembler benchmarks?"
This was prompted by the use of 1,000 occurrences of "stdout.put"
macro invocations (each of which expanded to an average of about
600-1,000 lines of code) and resulted in a 5 minute assembly time for
the adventure game. Now, it's not like HLA is particularly fast, but we
were talking about 1,000,000 lines of source code being processed here,
and by an interpreter, no less. Oh, the anti-HLA crowd had a field
day with that one (Rene made the claim that "no SpAsm/RosAsm
assembly could ever take five minutes", which I prompted proved
wrong). Note that when we replaced the invocations of "stdout.put"
with direct calls to routines like "stdout.puts", assembly time dropped
from five minutes to just a few seconds. Largely because HLA wasn't
processing a million lines of complex source code (as is present in
the stdout.put macro). It's not like HLA's macro processor is blazing
fast at this point (HLA v2.0 will be better), but you're going to have
the problem no matter how efficient the CTL is. That's why it's best
to build commonly-used items directly into the language.
Cheers,
Randy Hyde
Herbert Kleebauer
> C wrote:
> > Kain wrote:
> > > If it can be done by macros, why bother building it into the
> > > assembler?
> > I agree completely, plus having the HLLisms implemented
> > via CTL macros gives much greater flexability.
> Indeed, I'm far more radical than my LuxAsm compatriot, C (the person), is
> on the matter...we agree that it makes most sense to "externalise" the
> HLLisms...but I go further: I'd even be tempted to even "externalise" the
> _INSTRUCTION SET_ itself...
I think this is the wrong approach.
+----------------+
| xASM source |
| written in XYZ |
+----------------+
|
v
+----------------+
| XYZ compiler |
+----------------+
|
v
+-----------------+ +----------------+ +------------------+
| assembly source | -> | xASM binary | <- | macro definition |
+-----------------+ +----------------+ +------------------+
|
v
+----------------+
| user binary |
+----------------+
In this case you have to implement the macro engine as part
of your assembler xASM. If you shift up the macro definition
one level
+----------------+
| xASM source |
| written in XYZ |
+----------------+
|
v
+----------------+ +------------------+
| XYZ compiler | <- | macro definition |
+----------------+ +------------------+
|
v
+-----------------+ +----------------+
| assembly source | -> | xASM binary |
+-----------------+ +----------------+
|
v
+----------------+
| user binary |
+----------------+
then you don't need to implement a macro system at all. The macro language
is identical to the XYZ language. When ever you change a macro, the xASM
binary is automatically rebuilt from the xASM source and the macro
definitions. If XYZ is the assembly language itself (like in RosAsm),
then a macro is nothing but a small assembly program. But an assembly
language surely is one of the most inappropriate languages for
writing an assembler. If you use C as YXZ, you have the full power
of the C language as a macro language.
> And then you could even decide to not bother with "machine instructions"
> directly at all...you could create macros that implement some Pascal or
> BASIC-like high-level language...
That clearly shows that a powerful macro system is something
very bad. Suppose people stop to use well known languages
like English, French, German, .... and anybody designs his
own macro language. This would be the end of any communication.
The same can happen with an assembler with a powerful macro
system. If two people use this assembler and each uses his
own HL macro system, then both can use the same assembler
to compile their programs, but non is able to understand
the source of the other. This only makes sense if it either
is a one man project (so nobody else needs to understand
the source) or it has to be an open source project and you
want the source harder to understand than a disassembly of
the binary would be.
So, if you want to write an application, use one of the well
established HLL languages and if you need to go down to the
processor level, restrict yourself to the processor instructions
and avoid any complex macro.
C
> Beth wrote:
[snip]
>>And then you could even decide to not bother with "machine instructions"
>>directly at all...you could create macros that implement some Pascal or
>>BASIC-like high-level language...
>
> That clearly shows that a powerful macro system is something
> very bad. Suppose people stop to use well known languages
> like English, French, German, .... and anybody designs his
> own macro language. This would be the end of any communication.
Yes, this is the reason why the various attempts at meta-languages
failed -- the more power you give the user over the syntax the
more potential there is for the source to become less readable.
Luxasm is to partually addresses this problem by providing a
standard macro library of HLLisms which would be well designed
and tested. While the user would have the power to completely
rewrite such a library, there would be little point -- ie.
the user would have the power but not the need to use it.
C
2004-09-28
Kain
> "Randall Hyde" <rand...@earthlink.net> wrote:
> >Someone who refuses to use HLLism
> >can *still* use a high-level assembler the way that they want to, while
> >someone who *wants* to use HLLisms cannot use an assembler like
> >NASM or FASM the way they want to. High-level assemblers are
> >more flexible in this regard.
>
> Well, why someone that refuses to use HLLisms will stay with HLA?
> IMHO, that would be very strange person... :D
I don't think that was implied. The idea being stated (and repeated
many times) is that the HLLisms are there for mundane tasks which the
user may draw apon at will, if desired.
> Do you know such man? I am curious to read some of his sources.
> Also, in my observations - those that wants to use HLLisms, already uses
> C++ and Delphi.
>
> Regards
Those that use C++ and Delphi generally aren't interested in ASM, and
the in-line assembly of such products is useful for them when the need
arises.
As a user of HLA, I tend to use HLLisms in the form of procedures that
automate the frame and stack variables, simple if..endifs when I feel
too lazy to type out unimportant lables, records/structures and of
course, standard calls.
I dare say that all of the HLA features I make use of can also be done
with FASM, GoAsm, RosAsm and MASM (these are the ones I'm familiar
with, there are probably others) to some degree via use of macros and
other facilities.
So your next question might be, "why HLA and not one of the others?"
There is one simple reason:
Product loyalty.
When I wanted to learn asm, I tried out various products (the 4 I
mentioned above, plus HLA). Out of all those, AoA/32 with HLA was and
still is the best tool out of the 5 mentioned with which to learn
assembly.
Nevertheless, I learned with HLA, I'm comfortable with the syntax,
it's powerful enough for all my needs, it has a powerful library that
has saved me countless hours, so I stay with it as I have no reason to
switch.
This isn't to say that I'll never use another assembler. At some
times, I throw some FASM code toghther. HLA's FASM output has been a
great help in that respect too.
Beth
> Beth wrote:
is
> > on the matter...we agree that it makes most sense to "externalise" the
> > HLLisms...but I go further: I'd even be tempted to even "externalise"
the
> > _INSTRUCTION SET_ itself...
>
> I think this is the wrong approach.
Your opinion is noted and considered but I disagree...
> > And then you could even decide to not bother with "machine
instructions"
> > directly at all...you could create macros that implement some Pascal or
> > BASIC-like high-level language...
>
> That clearly shows that a powerful macro system is something
> very bad. Suppose people stop to use well known languages
> like English, French, German, .... and anybody designs his
> own macro language. This would be the end of any communication.
This is why we provide a "standard" as an integral part of the package...
Note that, strictly, "printf", "scanf", the start-up code that calls "main"
and so forth from C / C++ are NOT actually generated by the compiler but
are just object code / library files that are linked to the
program...hence, these are NOT part of "C the language" but are part of "C
the overall system"...
Same basic concept with LuxAsm...a set of "standard" files are provided
with the package and these provide that communication "standard" you're
worried about...although, just like C (or HLA), you can also ignore that
"standard library" and _decide_ to, as I stated, implement something of
your own...now, as you rightly point out, this would _inherently_ be
"non-standard"...unique...but, you know, sometimes that's _exactly what is
required_...when that is what's required, use LuxAsm without the
"standard"...all other occasions, use LuxAsm _with_ the "standard"
provided...
The LuxAsm authors are not responsible for a bad decision made by a
programmer due to ignorance...oh, we'll be glad to help to try to resolve
the misunderstanding...but - and perhaps this really needs to be stressed
with the amount of "philosophy pushing" around with many other tools -
LuxAsm isn't here to tell you how to program...the decisions of the team
are based on _providing service and facilities_ to programmers, not
"dictating" how you should live your life or something...
I will say this...if the current plans for LuxAsm pan out as intended and
expected, then I will make the guarantee that - through this approach we're
taking - "real assembly coders" will be just as equally catered for as
"high level assembly coders"...I'm fighting, indeed, on the LuxAsm list to
be quite _strict_ in making the lowest level implemented in the assembler
itself as _low-level_ and "real assembly" as possible, with completely
delibrate design that any and all "HLLisms" are _EXTERNALISED_...you don't
want? Then don't "#include" anything and you get yourself a 100% "real"
low-level assembler...if you do want, then the facilities are only an
"%include" away...
Truly, even Rene should completely appreciate this...though we're using
"#include" rather than "PREPARSE" - a different method of implementation
(we're not "monofile" but "modular" primarily so this difference in
implementation is to be expected...it's the natural non-"monofile" method
to approach it :) - this is entirely the "optional (externalised) HLLisms"
that Rene advocates and implements himself...the difference relates to the
implementation and that the LuxAsm team does not mandate that such macros
can't be used as "black boxes" when the programmer wants to use them as
"black boxes"...the point, though, is that when "externalised" in this
manner, whether the macro is a "black box" or not, comes down to whether
the programmer loads in the macro file and bothers to read the code to see
what it does or not...with _ALL_ "HLLisms" _STRICTLY_ "externalised" in
this manner, then you can _always_ go look at the macro (or change it or
whatever) as and when you feel like and, thereby, it ceases to be "black
box"...
My "philosophy" - which C and myself seem to completely share, as far as I
can see, that this will undoubtedly be LuxAsm's "philosophy" in the end -
is simply that all such decisions be placed in the programmers'
hands...this equally means providing "HLLisms" for those that want to
choose to take that path, as it is to make sure that no "HLLisms" plague
"real assembly coders" who're just not interested in such things...
It's simple, really...a _programmer_ is there to _tell the tool_ what to
do...not for the tool to tell the programmer what to do...and, indeed, the
gist of what I propose is always based on the notion of "provide the
facilities but always let the programmer choose whether to use them or
not"...these "HLL" facilities _SHOULD_ be provided because this is what
some programmers want (those who use HLA or MASM or whatever obviously like
and use these things, they are, therefore, provided)...BUT, as equally
important, the presence of these facilities should in no way threaten the
options of those of the opposite persuasion...
And the solution I propose is nice and simple..."externalise" any and all
"HLLisms" _STRICTLY_ into accessible "standard macros" files included as
part of the LuxAsm package...the files are, therefore, available and those
who want such things place a "#include 'StdMacros.inc'" directive (or
whatever the file(s) will eventually be called ;) at the top of the file
(for people who like "HLLisms" then the "HLLism" of including a set of
"#include" directives at the top of the file is perfectly recognisable from
C coding, which follows a similar-ish strategy too ;)...if you're not
interested, then don't use the "#include" and those "HLLisms" are NOT EVEN
DEFINED...they have not been included, they do NOT "exist" as far as the
assembler is concerned while processing your source file (yes, you can even
call your labels by the names of "HLLism" macros in those include files
because, as you're not including them, there is no "name conflict"...this
might be bad practice, though, from the perspective of it ruling out using
the "#include" without changing all those names first...but, again, that's
the programmers' problem...no, not in a "nasty" way of "we don't care about
the programmer" but in terms of "we know what our job is and it's NOT to
tell the programmer what to do"...a case of "self-restraint" that I've been
advocating on the mailing list...not being careful enough about
_overstepping_ the responsibilities a tool author has is, indeed, a common
cause of _problems_ with other tools and languages...
Should you be using "HLLisms"? Should you be using "black box"? Should you
be coding "portably"? Should you be coding specifically?
Blah-blah-blah...simply, NOT OUR PLACE TO SAY...that's the programmer's
responsibility to decide because _they know better than we ever could_ what
makes the most sense for them and their applications...
Hence, the basic strategy is simple...you _can_ use "HLLisms" but you, just
as equally, can choose _NOT_ to use "HLLisms"...you _can_ look inside the
"black box", just as equally as you can't be bothered and just use it "as
is"...you _can_ code "portably", just as equally as you can code
specifically...you make these decisions based on how you use the tool...the
tool provides the options but _YOU_ make the decisions...the LuxAsm team
are not qualified better than you are to know what is the best approach for
you...we'd be stupid, therefore, to even try to "dictate" one way over
another...
There is _ONE_ implicit choice already made, though...LuxAsm is for
Linux...but that's part of the name and somewhat the "raison d'etre"...this
is not any "political" or "philosophical" or "ethical" statement in that,
though...now, as everyone probably knows, I _don't_ much like Microsoft but
I'm not saying "don't write Windows code"...that would be ludicrous and
hypocritical, anyway...I write Windows code myself, after all...but just a
case that LuxAsm is for Linux...that was an initial decision made so that,
simply, LuxAsm could be more _specific_ to the platform to dedicate its
support specifically towards that platform...it's a "specific assembler"...
Indeed, note that though the implementation is different, Rene also
advocates "user-defined macros" for HLLisms...that is LuxAsm's approach too
but the implementation is slightly different - that of "externalisation"
(RosAsm has no "external" in that sense) - but the concept is the
same...LuxAsm is also a "specific assembler"...source code in the
executable (but, again, as our implementation is different, it'll also
optionally be in the object code too (a "comment" section; LuxAsm will
recognise it and use it...other tools will skip over it because they don't
understand its significance)...again, RosAsm has no "object code" so it
wouldn't be implementing it this way)...GUI based (though, again, our
implementation is different so there is equally a "command prompt" method
supplied too)...
The point is that our implementation has significantly changed from
RosAsm...but the "spirit" has not been altered in that sense...it's a
"Linux interpretation" of RosAsm..."modularity" is somewhat non-optional on
the platform so it kind of has to be this way (though, indeed, I'd have
probably wanted to include this, anyway ;)...
> The same can happen with an assembler with a powerful macro
> system. If two people use this assembler and each uses his
> own HL macro system, then both can use the same assembler
> to compile their programs, but non is able to understand
> the source of the other. This only makes sense if it either
> is a one man project (so nobody else needs to understand
> the source) or it has to be an open source project and you
> want the source harder to understand than a disassembly of
> the binary would be.
Yes; But there are a set of "standard HLL macros" supplied...this
"standard" works to, well, somewhat obvious from the name itself,
"standardise" the HLL macros used so that anyone using those macros will
have the "standard" and will be able to make use of each other's macros...
BUT, if, indeed, it _IS_ a one man project or it _IS_ an open source
project where "internal standards" have been agreed or whatever, then that
option is as equally open to you too...
Again, this might be a novel concept with so many "dictatorial" tools
around, trying to tell you how to program but our approach is just to allow
a range of methods to be available and then it's up to the _programmers_ to
communicate amongst themselves as to which approach to take...
If you choose to implement your own HL macros, then, well, you reap what
you sow...no-one else can use or understand it without examining all your
HL macros...
Indeed, welcome to the _REAL_ world...no "nannies" telling you how to
program, no "dictators" forbidding you to do such-and-such...just a tool
that provides options...choices always have consequences...we're doing
NOTHING to "hide" that fact from anyone...if you choose to do that, then
that is the consequences of that choice...BUT we do attempt to supply a
wide range of _OPTIONS_ so that you can take other decisions and make other
choices that have different consequences...this is what's known as
Liberty...it can be scary at first, sure enough...but, soon enough, you'll
enjoy it so much, you'll fight tooth and claw to retain it at all
costs...it's your choice, so, simply, choose wisely...
> So, if you want to write an application, use one of the well
> established HLL languages and if you need to go down to the
> processor level, restrict yourself to the processor instructions
> and avoid any complex macro.
That is one possible option...LuxAsm can support that because you can
create two ELF object files (one from, say, GCC and one from LuxAsm :) and
then link them together...
Another possible option is to write an application entirely in a HLL...this
option is "supported" from the perspective that LuxAsm doesn't force you to
use it (it won't do anything silly like try to take over the OS and the
screen and force you to only use LuxAsm, forbidding you to use anything
else ;)...just use GCC instead...
Another possible option is to write an application entirely in machine
instructions...this option is fully supported by LuxAsm..
Another possible option is to write an application in assembly using a few
"HLLism" macros here and there, employing the "standard" set provided with
LuxAsm for "communication" and "standardisation" purposes...this option is
fully supported by LuxAsm...
Another possible option is to write an application with HLLism macros of
your own design...this option is fully supported by LuxAsm...
There are many possible options...LuxAsm attempts to support them all...it
is NOT our place to dictate which method a programmer takes...this is their
choice and responsibility...feel free, Herbert, to grab LuxAsm users (when
they eventually appear on the newsgroup asking questions and so forth :)
and try to convince them of your "vision" about what is good
programming...some may be grateful to hear your perspective (heck, I may
often disagree with you but your case is not without foundation and I'm at
least grateful to _hear_ your "dissenting" opinions, even if I won't
actually go with them :)...what we're doing is supporting all methods
(well, lots of methods, anyway...I can't really guarantee "complete
coverage", of course ;) and then the programmer chooses what they
want...perhaps, indeed, following a prescribed "philosophy" of programming
that you or Rene or Randy may advocate...
This is an assembly language tool for Linux, not some "lifestyle choice" or
anything...it is supplied without false idols and without "religion"...even
the "Linux only" part is merely _practicality_, not "philosophy", at least
in my case...program Windows if you want...this tool doesn't cater for that
because of its "specific" nature but no-one's telling you to do this or do
that...your life, your choice...to me, assembly language's power comes from
the _LIBERTY_ it provides (and I'm a great fan of "Liberty" in most of its
guises :)...I consider it a _bad move_ to unnecessarily restrict that
Liberty for what appears to be no practically useful reason
whatsoever..._OPTIONS_ is what makes assembly language and tools
powerful...that's the route we're taking...
"'Sweet dreams are made of this'
Who am I to disagree?
I've travelled the world
And the seven seas:
Everybody's looking for something.
Some of them want to use you
Some of them want to get used by you
Some of them want to abuse you
Some of them want to be abused
(Hold your head up)
(Movin' on)
(Keep your head up)
(Movin' on)"
[ "Sweet Dreams", Eurythmics, from the "1984" movie soundtrack ]
Beth :)
C
> (yes, you can even
> call your labels by the names of "HLLism" macros in those include files
> because, as you're not including them, there is no "name conflict"...this
> might be bad practice, though, from the perspective of it ruling out using
> the "#include" without changing all those names first...
Actually, if we get namespaces correctly implemented, even that may not
be a problem. :-)
C
2004-10-02
Herbert Kleebauer
> The LuxAsm authors are not responsible for a bad decision made by a
> programmer due to ignorance
> LuxAsm isn't here to tell you how to program...
Seems you have to do a market analyze which sort of people
will use LuxAsm. There is the group of professional programmer,
but I think a professional programmer will never use a tool like
LuxAsm (or RosAsm or HLA or ...) to write applications. Then we
have the group of hobby programmers and the group which wants
to learn assembly programming. Both of this groups may be a
target group for LuxAsm, but for both groups your statement
above isn't true. The LuxAsm authors are responsible for a
bad decision made by a programmer. It has to tell the programmer
how to program by don't allowing him to make a bad decision.
And to create his very own language which nobody else understands
is a bad decision.
> It's simple, really...a _programmer_ is there to _tell the tool_ what to
> do...not for the tool to tell the programmer what to do...
A taxi driver should drive in the direction you tell him, but should
he also drive against a wall if you tell him so?
> wide range of _OPTIONS_ so that you can take other decisions and make other
> choices that have different consequences...this is what's known as
> Liberty...it can be scary at first, sure enough...but, soon enough, you'll
> enjoy it so much, you'll fight tooth and claw to retain it at all
> costs...it's your choice, so, simply, choose wisely...
The liberty to choose between many options allows you to make
many wrong decisions. It is maybe much better to restrict your
liberty and don't allow you to make some of the worst decisions,
at least if you are not a professional and can't foresee the
consequences.
> that...your life, your choice...to me, assembly language's power comes from
> the _LIBERTY_ it provides (and I'm a great fan of "Liberty" in most of its
> guises :)...I consider it a _bad move_ to unnecessarily restrict that
> Liberty for what appears to be no practically useful reason
> whatsoever..._OPTIONS_ is what makes assembly language and tools
> powerful...that's the route we're taking...
What is the _LIBERTY_ of assembly programming? You can use a sequence
of processor instructions, but the instruction set is prescribed by
the processor designer, so your liberty is restricted to the choose
of the sequence. Or do you mean the liberty to not explicitly specify
the sequence but using HL constructs which then are converted by
an included macro library to an instruction sequence? That has
nothing to do with assembly programming. If you want HL constructs,
use a well designed and standardized HLL and don't define your private
macro set.
Randall Hyde
"Herbert Kleebauer" <kl...@unibwm.de> wrote in message
news:415EFE16...@unibwm.de...
> Beth wrote:
>
> > The LuxAsm authors are not responsible for a bad decision made by a
> > programmer due to ignorance
>
> > LuxAsm isn't here to tell you how to program...
>
> Seems you have to do a market analyze which sort of people
> will use LuxAsm. There is the group of professional programmer,
> but I think a professional programmer will never use a tool like
> LuxAsm (or RosAsm or HLA or ...) to write applications.
"a professional programmer"
Easy statement to make. All you've got to do is find *one*
professional programmer who will never use a tool like these.
As there are many professional programmers who use MASM,
I guess this is an immediate QED.
A stronger statement would be "no professional programmer would..."
But, of course, that is unsupportable.
> Then we
> have the group of hobby programmers and the group which wants
> to learn assembly programming. Both of this groups may be a
> target group for LuxAsm, but for both groups your statement
> above isn't true. The LuxAsm authors are responsible for a
> bad decision made by a programmer.
Yes, and gun manufacturers are responsible for all firearm-related
homicides, cigarette manufacturers are responsible for all lung
cancer cases, spirit distillers are responsible for all drunk-driving
accidents, etc.. We've heard all these arguments before.
> It has to tell the programmer
> how to program by don't allowing him to make a bad decision.
Dictators often use similar claims. The "people" don't know what's
good for them. Only the "true leader" knows how to make right
decisions.
> And to create his very own language which nobody else understands
> is a bad decision.
Yes. We should all be using FORTRAN today. No need to design
new languages.
>
> > It's simple, really...a _programmer_ is there to _tell the tool_ what to
> > do...not for the tool to tell the programmer what to do...
>
> A taxi driver should drive in the direction you tell him, but should
> he also drive against a wall if you tell him so?
Then again, if *you're* in the driver's seat, nothing stopping you
from driving into that wall if you really want to, eh? Call it Darwinism.
If you create your own languages and this is a real problem for the
rest of the world, and that's a problem, either you'll adapt or the
world will adapt. In the end, it all balances out.
Yep, some people could create some horrid "mini-languages" using
something like LuxAsm. Code that no one will want to read or
maintain. OTOH, they could also create the "next big thing" in
programming language design. Remember when Microsoft
first introduced HLL-like statements in MASM? Their presence
was universally panned by "true-blue" assembly programmers.
Today, their use in Win32 apps is widely accepted.
> The liberty to choose between many options allows you to make
> many wrong decisions. It is maybe much better to restrict your
> liberty and don't allow you to make some of the worst decisions,
> at least if you are not a professional and can't foresee the
> consequences.
Spoken like a true dictator.
Look, you can easily achieve this without burdening the tool.
The tool should have the flexibility to allow the programmer to
do whatever they want. For the beginners, for whom that freedom
could create problems, you limit their choices via the available
pedagogy. For example, HLA has a ton of fancy, advanced,
features that would be overwhelming for a beginner to learn.
Little of this is discussed in "The Art of Assembly Language".
Similarly, pedagogy for a system like LuxAsm, aimed at beginners,
could emphasize the straight machine code without all the fancy
meta-language stuff. Once that beginner is comfortable with
the basics, *then* they can go on to learn the advanced stuff
on their on.
> What is the _LIBERTY_ of assembly programming? You can use a sequence
> of processor instructions, but the instruction set is prescribed by
> the processor designer, so your liberty is restricted to the choose
> of the sequence. Or do you mean the liberty to not explicitly specify
> the sequence but using HL constructs which then are converted by
> an included macro library to an instruction sequence? That has
> nothing to do with assembly programming. If you want HL constructs,
> use a well designed and standardized HLL and don't define your private
> macro set.
And don't define your own functions/procedures/subroutines while your
at it. And don't define your own data types, either.
Why are control structures sacrosant? Every programming book I've
seen extolls the benefits of user-defined subroutines and data types.
Why not control structures? There's nothing magical about control
structures. Assembly programmers create new control structures all
the time. All a macro (or template) does is *standardize* a sequence
of instructions appearing in a program so that the reader only has
to recognize an identifier name rather than having to match a long
sequence of instructions against a common operation. Like subroutines,
application-defined control structures can be a good thing. Like
subroutines (and data types), yes, they can be abused. But limiting
macro facilities is not going to stop someone from abusing language
features. If they're an abusive type, they'll abuse other things in their
apps. OTOH, in the hands of someone who *can* do a good job
of using abstractions, macros come in real handy, produce more readable
code, more maintainable code, and so on.
Language designers should concentrate on providing facilities that
are useful to *good* programmers rather than worrying about
how *poor* programmers might abuse those features.
There's really nothing that can be done to correct the abominations
a *bad* programmer can come up with. No matter how you restrict them,
they're going to write bad code. So it's a better idea to provide facilities
that *good* programmers can use to write more effective code.
Cheers,
Randy Hyde
John Found
>Today, their use in Win32 apps is widely accepted.
M-m-m-m, I can see only few Win32 applications in assembly language
- high or low level... So, what the word "widely" means for you?
Maybe "widely" used in the books, examples and demos for Win32?
Regards
John Found
Randall Hyde
Of the Win32 apps, demos, tutorials, and utilities written, most of them
use these constructs.
Check out the internet sometime, you'll find *lots* of sample code written
this way. I'm sorry you'll find that most of the samples are short, not the
75,000 LOC apps you'd like to find, but regardless, there is quite a bit
of code out there.
Cheers,
Randy Hyde
Herbert Kleebauer
> "Herbert Kleebauer" <kl...@unibwm.de> wrote in message
> > Seems you have to do a market analyze which sort of people
> > will use LuxAsm. There is the group of professional programmer,
> > but I think a professional programmer will never use a tool like
> > LuxAsm (or RosAsm or HLA or ...) to write applications.
> As there are many professional programmers who use MASM,
> I guess this is an immediate QED.
I wrote "LuxAsm (or RosAsm or HLA or ...)" and MASM surely isn't
part of the "...". MASM builds a team with Microsoft's HL languages
and many (if not most) professional Windows programmers use
Microsoft's C compiler. MASM is used as a low level support
tool for VC++ (as GAS is used for GCC), but show me an actual
commercial applications written completely with MASM or GAS. It
isn't sufficient to add a few HL constructs, either in form of a
macro system (as in LuxAsm or RosAsm) or built-in like in HLA,
to get a tool which can competed with a e.g. a C/ASM pair.
> Yes, and gun manufacturers are responsible for all firearm-related
> homicides, cigarette manufacturers are responsible for all lung
> cancer cases, spirit distillers are responsible for all drunk-driving
> accidents, etc.. We've heard all these arguments before.
Maybe you would change your mind if one of your children is
killed through one of this examples.
> > It has to tell the programmer
> > how to program by don't allowing him to make a bad decision.
>
> Dictators often use similar claims. The "people" don't know what's
> good for them. Only the "true leader" knows how to make right
> decisions.
Do you really not see the difference? You can tell the people
what they have to do to maximize your profit, or you can tell
them what to do because you care about them. Would you allow
you 12 year old son to drink and smoke as much as he like
because it is his own decision to do what ever he likes? If
you only care about your own success, you can create something
like HLA and sell it as a tool for teaching assembly programming
but if you would care about these people and try to really teach
them assembly programming you would never use HLA.
> > And to create his very own language which nobody else understands
> > is a bad decision.
>
> Yes. We should all be using FORTRAN today. No need to design
> new languages.
The design of a new language should be done by a group of
experts but not every hobby programmer should create his
private language.
> If you create your own languages and this is a real problem for the
> rest of the world,
It is not a problem for the rest of the world, it is a problem
for yourself. It is also not a problem for the rest of the
world if you drink or smoke. So, if you don't care about other
this is no problem at all. But if you care about other, then
you should try to make it difficult for other to start drinking
and smoking.
> Yep, some people could create some horrid "mini-languages" using
> something like LuxAsm. Code that no one will want to read or
> maintain.
Yes, some people could get problems if you distribute drugs
for free,
> OTOH, they could also create the "next big thing" in
but they could also be so inspired by the drugs to invent
some great things. But I still think it is a bad thing
to distribute drugs.
> > The liberty to choose between many options allows you to make
> > many wrong decisions. It is maybe much better to restrict your
> > liberty and don't allow you to make some of the worst decisions,
> > at least if you are not a professional and can't foresee the
> > consequences.
>
> Spoken like a true dictator.
No, spoken like somebody who cares about other.
> Look, you can easily achieve this without burdening the tool.
> The tool should have the flexibility to allow the programmer to
> do whatever they want. For the beginners, for whom that freedom
> could create problems, you limit their choices via the available
> pedagogy.
But as I said above, no professional programmer would use
that tool. Now, if you limit the features of the tool for
all people who ever use the tool, then, which sense does
it make to implement this features?
> And don't define your own functions/procedures/subroutines while your
> at it. And don't define your own data types, either.
There is a big difference between the use of a language (to define
subroutines and data structures) and the definition of a new
language.
Let's use the keyboard as an example. There are a few different
layouts, QWERY in US or QWERTZ in Germany, but most letters
are at the same position so it is no big problem to use the
PC of somebody else. Now suppose, that keyboards wouldn't
have a predefined layout but every user can specify his preferred
key <-> letter assignment. In this case you will have big
trouble if you have to use the PC of somebody else.
If a program is written in a widely known language, then it
is much easier to understand the program than if the program
is written in a self defined language.
> Language designers should concentrate on providing facilities that
> are useful to *good* programmers rather than worrying about
> how *poor* programmers might abuse those features.
Language DESIGNERS should choose a proper syntax for the
language and not allow the USER to completely redesign
the language. This means, the HL constructs have to be
built into the compiler and not to be loaded as macro
definitions which easily can be changed by the user.
(But don't forget, it isn't an assembler any more.)
Randall Hyde
>
>
> > Yes, and gun manufacturers are responsible for all firearm-related
> > homicides, cigarette manufacturers are responsible for all lung
> > cancer cases, spirit distillers are responsible for all drunk-driving
> > accidents, etc.. We've heard all these arguments before.
>
> Maybe you would change your mind if one of your children is
> killed through one of this examples.
No. I place the responsibility with the person who pulled the trigger,
drank and drove, or chose to smoke.
>
> Do you really not see the difference?
Yes, as a matter of fact, I do.
You think you know the only true way and you want to
force your decisions onto other people.
> You can tell the people
> what they have to do to maximize your profit, or you can tell
> them what to do because you care about them.
Telling them *how* they should behave, and preventing them
from behaving in a way that you don't like are two different
things. Perhaps *you* do not see the difference?
> Would you allow
> you 12 year old son to drink and smoke as much as he like
> because it is his own decision to do what ever he likes?
Most of us around here are mature enough to make our own
decisions. We don't need *you* playing "papa" for us.
> If
> you only care about your own success, you can create something
> like HLA and sell it as a tool for teaching assembly programming
> but if you would care about these people and try to really teach
> them assembly programming you would never use HLA.
Quite the contrary. HLA has proven *extremely* successful
as an assembly language teaching tool. It has made students
far more productive than they were when using tools like MASM
to write DOS applications in assembly.
But guess what? I'm not telling people they *have* to learn assembly
that way. I only offer them a different choice if learning traditional
assembly in a traditional fashion isn't quite as efficient as they'd like.
You, on the other hand, simply want to limit their options.
>
>
> > > And to create his very own language which nobody else understands
> > > is a bad decision.
> >
> > Yes. We should all be using FORTRAN today. No need to design
> > new languages.
>
> The design of a new language should be done by a group of
> experts but not every hobby programmer should create his
> private language.
Yes. Only the "elite" are qualified to do this.
Again, a very dictatorial attitude.
"Liberty" is the ability for *anyone* to use their creativity
to create whatever they want; whether or not you agree with
what they are doing.
>
>
> > If you create your own languages and this is a real problem for the
> > rest of the world,
>
> It is not a problem for the rest of the world, it is a problem
> for yourself. It is also not a problem for the rest of the
> world if you drink or smoke. So, if you don't care about other
> this is no problem at all. But if you care about other, then
> you should try to make it difficult for other to start drinking
> and smoking.
Difficult, perhaps. Impossible, no.
It *is* difficult for a beginner to create their own language using
macros in an assembly language development system like LuxAsm,
MASM, HLA, whatever. People have to learn quite a bit about
macros, parsing, code generation, etc., in order to pull this off.
A "beginner" is not going to be able to do this. By the time that
beginner gains enough experience to successfully achieve this,
why would you want to limit their capabilities?
>
>
> > Yep, some people could create some horrid "mini-languages" using
> > something like LuxAsm. Code that no one will want to read or
> > maintain.
>
> Yes, some people could get problems if you distribute drugs
> for free,
>
> > OTOH, they could also create the "next big thing" in
>
> but they could also be so inspired by the drugs to invent
> some great things. But I still think it is a bad thing
> to distribute drugs.
And it's a bad thing to let people drive cars (they can get in
accidents), it's a bad thing to let people eat fast food (they'll
get fat), and so on and so forth.
Face it, you're a control freak. You want to control everyone
else's life so the world fits into your little picture of how things
should be. In a sense, we're all like this. But some of us are
wise enough to realize that, in the long run, it's much better
to let people do as they choose, particularly when their choices
don't affect anyone else. Empowering assembly programmers
with decent tools that let them create applications the way
*they* want to, rather than the way some "programming on
the fringe" feels they ought to be written, doesn't place much
of a burden on society. :-)
>
>
> > > The liberty to choose between many options allows you to make
> > > many wrong decisions. It is maybe much better to restrict your
> > > liberty and don't allow you to make some of the worst decisions,
> > > at least if you are not a professional and can't foresee the
> > > consequences.
> >
> > Spoken like a true dictator.
>
> No, spoken like somebody who cares about other.
Cares? In what way?
In a way that you'd prevent them from doing their job the
way they want to do it? What arrogance! You actually think
you know best for everyone? Care all you want. Just keep
your cares to yourself. The rest of us are quite happen getting
good tools (like LuxAsm) that help us solve *our* problems.
>
>
> > Look, you can easily achieve this without burdening the tool.
> > The tool should have the flexibility to allow the programmer to
> > do whatever they want. For the beginners, for whom that freedom
> > could create problems, you limit their choices via the available
> > pedagogy.
>
> But as I said above, no professional programmer would use
> that tool. Now, if you limit the features of the tool for
> all people who ever use the tool, then, which sense does
> it make to implement this features?
No, you didn't say "no professional programmer." You said
"a professional programmer."
Once you say "no..." the statement is patently false.
Professional programmers use tools like these all time.
Just because, in your limited experience, you don't see this
doesn't mean that professional programmers aren't using these
tools. Indeed, the *vast* majority of professional assembly
programmers use MASM. And it has many of the capabilities
that you claim no professional programmer would use. And
those professional programmers are *using* those facilities.
>
>
> > And don't define your own functions/procedures/subroutines while your
> > at it. And don't define your own data types, either.
>
> There is a big difference between the use of a language (to define
> subroutines and data structures) and the definition of a new
> language.
We are talking about using macros to extend the language, remember?
Try looking up "Embedded Domain Specific Languages" sometime.
That's exactly what you can create by "using a language" that has
appropriate features (e.g., HLA and, presumably, LuxAsm).
>
> Let's use the keyboard as an example. There are a few different
> layouts, QWERY in US or QWERTZ in Germany, but most letters
> are at the same position so it is no big problem to use the
> PC of somebody else. Now suppose, that keyboards wouldn't
> have a predefined layout but every user can specify his preferred
> key <-> letter assignment. In this case you will have big
> trouble if you have to use the PC of somebody else.
There's a problem with your analogy. People can't simply
"read a keyboard layout document" and use the new keyboard.
They can, however, read a header file with macro definitions
and easily determine how those macros operate in the code
(within weeks or months of training to become proficient).
At least, if they are half-way competent, they can.
>
> If a program is written in a widely known language, then it
> is much easier to understand the program than if the program
> is written in a self defined language.
Again, defining control structures to extend a "language"
is really no different than extending that language via
functions, subroutines, procedures, macros, and user-defined
data types.
The fact that I can sit down and write my own versions of
all the C standard library routines, with completely different
semantics, surely demonstrates that I can do just as much
evil with function definitions as I could with control structure
definitions. Conversely, by applying decent software engineering
techniques, I can make a program more readable by creating
specialized control structures (in a language that allows this)
just as I can make a program more readable and maintainable
using custom written functions. Yep. It takes experience to
know when to do this, how to do it properly, etc., etc., but
that's no different than writing functions or creating user-defined
data types.
>
>
> > Language designers should concentrate on providing facilities that
> > are useful to *good* programmers rather than worrying about
> > how *poor* programmers might abuse those features.
>
> Language DESIGNERS should choose a proper syntax for the
> language and not allow the USER to completely redesign
> the language.
They will never be able to completely redesign the language :-)
But they should be able to extend it. After all, that was the
original purpose for subroutines, to extend the capabilities of
programming languages. That's why users were given the
ability to create user-defined data types -- to extend the language.
You don't see anyone complaining about how USERS shouldn't
be able to create their own data types, do you?
> This means, the HL constructs have to be
> built into the compiler and not to be loaded as macro
> definitions which easily can be changed by the user.
> (But don't forget, it isn't an assembler any more.)
First of all, who says that the language constructs have to
be high-level? Maybe I want to create a "jump on overflow
or equal" statement in my assembly language (because a
particular application I'm writing uses that particular construct
quite a bit). Maybe I just want to create a set of IFE, IFNE,
IFLT, IFGT, IFLE, IFGE, etc., statements that do a JNcc
around a block of statements. This is all low-level stuff.
Second, why should the user be limited to the macros that
the language designer builds into the language? Experts or
otherwise, language designers don't get everything right (if they
did, we'd all be using the "one perfect language" today).
Users should have the ability to extend their languages
as they see fit for their applications. This concept is nothing
new, btw, languages like Lisp have been around a long time
and have supported this capability. Modern languages like
Haskell and Dylan provide this capability today (in HLLs
and VHLLs). It's only reasonable that an assembler,
like LuxAsm, could provide this capability, too.
Cheers,
Randy Hyde
Percival
> "Herbert Kleebauer" <kl...@unibwm.de> wrote in message
> news:415F4885...@unibwm.de...
>
>>
>>>Yes, and gun manufacturers are responsible for all firearm-related
>>>homicides, cigarette manufacturers are responsible for all lung
>>>cancer cases, spirit distillers are responsible for all drunk-driving
>>>accidents, etc.. We've heard all these arguments before.
>>
>>Maybe you would change your mind if one of your children is
>>killed through one of this examples.
>
>
> No. I place the responsibility with the person who pulled the trigger,
> drank and drove, or chose to smoke.
While i agree, I hope we all realize that this isn't a black and white
issue. I personally agree with Randall here in these spesific places,
however...
Assault weapons, Crack and Heroin, Weed are all controvercial because of
this argument. Personally, I place myself that assult weapons are fine
if the checks are in place (I want more background checks and stricter
security however) , Crack Heroin should not be manufactured, and as soon
as i find something bad about weed I'll place it into the catagory with
the rest of the drugs. But first, I need to get an argument against that
drug. Even ciggarette smoking is controversial where I am, as
second-hand smoke was a problem in the past.
But I understand how controversial these are, and I am just putting them
up as examples, not to argue about it.
>>You can tell the people
>>what they have to do to maximize your profit, or you can tell
>>them what to do because you care about them.
>
> Telling them *how* they should behave, and preventing them
> from behaving in a way that you don't like are two different
> things. Perhaps *you* do not see the difference?
Yes. Not everyone is the same. By assuming you are in a better position,
and assume everyone else doesn't mind changing their ways to be more
like you.
>>Would you allow
>>you 12 year old son to drink and smoke as much as he like
>>because it is his own decision to do what ever he likes?
>
>
> Most of us around here are mature enough to make our own
> decisions. We don't need *you* playing "papa" for us.
Age restrictions exist for a reason.
>>>>And to create his very own language which nobody else understands
>>>>is a bad decision.
>>>
>>>Yes. We should all be using FORTRAN today. No need to design
>>>new languages.
>>
>>The design of a new language should be done by a group of
>>experts but not every hobby programmer should create his
>>private language.
So ADA was a good idea then? Linux is a bad idea because it started as a
hobby? Hobbiests SHOULD be able to change the world.
[snips the low blows]
>>>Language designers should concentrate on providing facilities that
>>>are useful to *good* programmers rather than worrying about
>>>how *poor* programmers might abuse those features.
>>
>>Language DESIGNERS should choose a proper syntax for the
>>language and not allow the USER to completely redesign
>>the language.
>
>
> They will never be able to completely redesign the language :-)
> But they should be able to extend it. After all, that was the
> original purpose for subroutines, to extend the capabilities of
> programming languages. That's why users were given the
> ability to create user-defined data types -- to extend the language.
> You don't see anyone complaining about how USERS shouldn't
> be able to create their own data types, do you?
Erm... One reason Lisp is still popular today is because you can create
a different language using lisp.
Percival
Ro
wrote:
>Randall Hyde wrote:
>> "Herbert Kleebauer" <kl...@unibwm.de> wrote in message
>
>> > Seems you have to do a market analyze which sort of people
>> > will use LuxAsm. There is the group of professional programmer,
>> > but I think a professional programmer will never use a tool like
>> > LuxAsm (or RosAsm or HLA or ...) to write applications.
>
>> As there are many professional programmers who use MASM,
>> I guess this is an immediate QED.
>
>I wrote "LuxAsm (or RosAsm or HLA or ...)" and MASM surely isn't
>part of the "...". MASM builds a team with Microsoft's HL languages
>and many (if not most) professional Windows programmers use
>Microsoft's C compiler. MASM is used as a low level support
>tool for VC++ (as GAS is used for GCC), but show me an actual
>commercial applications written completely with MASM or GAS. It
>isn't sufficient to add a few HL constructs, either in form of a
>macro system (as in LuxAsm or RosAsm) or built-in like in HLA,
>to get a tool which can competed with a e.g. a C/ASM pair.
so for you nothing can change the things, for me you are too
self-confident