High Level ASM and Low Level ASM 
Author Message
 High Level ASM and Low Level ASM

Whats the difference between high level and low level Assembly?


Sat, 19 Jul 2003 18:48:34 GMT  
 High Level ASM and Low Level ASM
On Tue, 30 Jan 2001 18:48:34 +0800, "Assembly"

Quote:

>Whats the difference between high level and low level Assembly?

"High level assembly" & "low level assembly" are not part of the
glossary -but I know what you mean.

IMO:

An assembler is anything which allows you to have full control of the
generated code. MASM, for instance, allows for this.

But MASM also has some high level features, in that you can write
statements that are more than simple CPU instructions. For instance,

  INVOKE ExitProcess, 0

This is being translated by MASM into

  Push 0
  Call ExitProcess

Here, nonetheless, you can know beforehand which is the generated
code, and that *exactly*. So I would say in this respect MASM is a
"high level assembler". A compiler, on the other hand, does not
guarantee you the generated code *exactly*. A Pascal statement as

  ExitProcess (0);

shall most probably be translated as

  Push 0
  Call ExitProcess

same as MASM. But there's no guarantee it shall be so. You are only
guaranteed (as long as the compiler is not a buggy one, of course)
that it shall in the end do those two CPU instructions, but it may add
all sort of instructions, even useless or repetitive ones, without
affecting the practical result. This depends on the quality of the
compiler, the IO checks which are required of it, etc. And what one
Pascal compiler may generate, is not necessarily the same as what's
being generated by another. You even have no guarantee that the
generated code shall be the same along different versions of the
compiler.

HLA (High Level Assembly) is a programming tool which offers a lot of
high level features, while:

 -- being an assembler, because you can always have full control of
generated code.

 - guaranteeing you can know beforehand *exactly* the generated code
for its high level statements.

So, the HLA language could be called "high level assembly", to use
your own terms. But HLA also allows you to code in "low level
assembly". You can even disregard every high level feature of HLA, and
just use it as a "low level assembly" tool.

Manuel Algora



Sat, 19 Jul 2003 20:06:20 GMT  
 High Level ASM and Low Level ASM

Quote:
>Whats the difference between high level and low level Assembly?

If you're referring to the HLA (High Level Assembler) it's an attempt
to make programming in assembly seem more like programming in a higher
level language, such as C.

If you're just referring to the general meaning then it would probably
relate to programming in a macro assembler (by writing a text file
which is then compiled/assembled by an assembler) vrs directly writing
machine code.

In a high level assembler you can do stuff like this:

    my_variable   dw 200
    .
    .
    .
    mov ax,my_variable

In a low level assembler you could not do symbollic mov's.  Everything
would have to be known, such as:

    mov ax,200
        ; or
        mov ax,word ptr [whatever_offset_200_is_at]

- Rick C. Hodgin



Sat, 19 Jul 2003 23:45:21 GMT  
 High Level ASM and Low Level ASM


   >Whats the difference between high level and low level Assembly?

There's no such thing as 'high level' or 'low level assembly.'

You're probably referring to the 'HLA Assembler' (tm) or to
the 'HLA Programming Language' (tm), which is mentioned overly-
often in these precincts.

'HLA' (tm) is merely a trade-mark name which software author
Randy Hyde gave to a particular software program he wrote.

'HLA' (tm) is aimed primarily at university students who are
already somewhat familiar with a standard 'high-level' programming
language (such as C or Turbo Pascal).

'HLA' (tm) supposedly makes it 'easier' for those unmotivated
skulls-full-of-mush to learn assembly language programming.

'HLA' (tm) presents students with a totally non-standard and
proprietary method of code-writing.  This method vaguely resembles
the conventions they learned while studying normal 'high level'
programming languages.

But 'HLA' (tm) code is not usable 'assembly language.'

This 'HLA' (tm) code must be processed by the 'HLA Assembler' (tm).
The 'HLA Assembler' (tm) emits =real= assembly-language code,
which must then be assembled into an executable file by a =real=
assembler (usually MA$M -- if one considers that a 'real' assembler).



Sun, 20 Jul 2003 08:22:48 GMT  
 High Level ASM and Low Level ASM
HLA is public domain and certainly not trademarked by
Randy Hyde :-)

At one time, someone claimed in this newsgroup (or in
CLAX) to have trademarked "HLA" and "High Level
Assembly", but I pointed out that both IBM and Motorola
have used products with these names for well over a decade
and the matter was quickly dropped.

Perhaps an IBM (360/370/etc) assembly programmer can
explain why IBM called their product HLASM;  personally,
I could find nothing high level at all about it.
Randy Hyde


Quote:


>    >Whats the difference between high level and low level Assembly?

> There's no such thing as 'high level' or 'low level assembly.'

> You're probably referring to the 'HLA Assembler' (tm) or to
> the 'HLA Programming Language' (tm), which is mentioned overly-
> often in these precincts.

Hey, HLA's popularity is increasing by leaps and bounds because
of my "over promotion."  I make no apologies whatsoever at all.

Quote:

> 'HLA' (tm) is merely a trade-mark name which software author
> Randy Hyde gave to a particular software program he wrote.

See above.

Quote:

> 'HLA' (tm) is aimed primarily at university students who are
> already somewhat familiar with a standard 'high-level' programming
> language (such as C or Turbo Pascal).

> 'HLA' (tm) supposedly makes it 'easier' for those unmotivated
> skulls-full-of-mush to learn assembly language programming.

Actually, HLA is targeted for two groups:  "unmotivated skulls-full-of-mush"
students and very advanced assembly programmers (i.e., me).

Actually, I'll agree 100% with the term "unmotivated."  However,
I'd point out that most University students (particularly those being
forced to take an assembly class) are quite a bit brighter than the
average citizen.  Granted, most students are not taking the course
because they want to learn assembly language.  Indeed, in a typical
class with 50 students I seriously doubt more than 3 or 4 were
truly interested in the subject.  However, part of the challenge in such
a course is to get about 5-10 students really interested in the language
by the end of the course and ensure that at least half the course (25
students) are reasonably proficient in assembly language by the
end of the quarter (ten weeks).  Of the remaining 25 students,
typically 15 would drop the course and the remainder probably
should have.  These were typical numbers when I taught the course
with MASM.

The last quarter I used HLA, I started with 87 students and had
roughly 20 drop the course.  Another 5-10 really should have.
That left slightly more than 50 students who were producing
reasonable projects by the end of the quarter.
(the numbers above are approximates, but the real number I
remember is that two-thirds of the class finished the course
reasonably well compared to one-half;  furthermore, the final
projects were *much* better than they had been in previous
years).

Another benefit of the course, is that about 20 students did
extremely well and left the course e{*filter*}d about assembly
language (i.e., they were planning on writing personal projects
in assembly after the completion of the course).  This is a
much higher percentage than I'd ever achieved before from
a group of "unmotivated students."

Do keep in mind, students typically take several other
courses (usually three) concurrently with an assembly
course.  You can't assume the students can spend 100%
of their time learning this subject.  In fact, most Universities
have policies about how much student time an instructor
can use per week for a course.  At UCR the numbers
are roughly the following (for the assembly course):
3 hours/lecture/week, 3 hours lab/week, 9 hours homework, prep,
and programming projects per week.  My course was famous
for completely violating these numbers (the average student
spent about 20 hours/week on my course;  which explains
the high attrition rate -- if you're taking three other heavy
courses concurrently you'd be working 80 hours/week which
is way too much).

I didn't reduce the workload upon introducing HLA into
the course.  However, HLA did allow the students to get
much farther along in ten weeks than they did with MASM.

Making unmotivated students work harder (to get as far
as they got with the HLA version of the course) is not
an option;  I already exceed the workload specified by
University policy.  HLA does make more efficient use
of the time that is available.

The bottom line- students learned more assembly language.
Regardless of their motivation or native intelligence, this
is a good thing.

Quote:

> 'HLA' (tm) presents students with a totally non-standard and
> proprietary method of code-writing.  This method vaguely resembles
> the conventions they learned while studying normal 'high level'
> programming languages.

Every assembler out there is totally non-standard and proprietary.
The "standard" was Intel's ASM-86 (which they don't even make
anymore).  MASM has it's high level language features (upon which,
btw, HLA's were based).  TASM has it's IDEAL mode.  NASM
has it's own syntactical peculiarities, and Gas, of course, is off in
it's own universe.  Why is HLA any different?  Because it's not
a MASM clone?  There would be no reason for HLA if it
weren't different.  Certainly, people wouldn't find assembly language
programming easier to learn if HLA were a knock-off of MASM in
the same way that NASM was a knock-off of Intel's syntax.

Quote:

> But 'HLA' (tm) code is not usable 'assembly language.'

Why?
You've made a very strong claim.  Now support it.
What can't you do with HLA that you can do with other
assemblers?  There are a few examples: you can't write
16-bit segmented code (unnecessary for most modern
assembly applications).  Writing an operating system
with HLA would require dropping down to a lower
level for the initialization code.  I don't think I'd use
HLA to write embedded systems code (unless it
was a WinCE/CEPC or embedded NT system).
But for Win32 applications, I fail to see what you can
do with MASM that you couldn't also do with HLA.
Perhaps you could enlighten me?

Quote:

> This 'HLA' (tm) code must be processed by the 'HLA Assembler' (tm).
> The 'HLA Assembler' (tm) emits =real= assembly-language code,
> which must then be assembled into an executable file by a =real=
> assembler (usually MA$M -- if one considers that a 'real' assembler).

The HLA *compiler* emits assembly code that must be processed
by the MASM assembler.  This has very little to do with the design
of the HLA language.  This is an implementation decision I made
in order to make designing and testing the HLA *prototype* a whole
lot easier.  There is no technical reason why HLA couldn't generate
object code directly;  indeed, HLA v2.0 will do this.

Of course, you don't consider MASM to be a real assembler (based
on the last remark above).  That being the case, I'll not bother
arguing with you about whether HLA is a *real* assembler.
HLA's machine instructions and high level control structures are
very similar.  The syntactical variations as far as a *language*
is concerned are trivial (e.g., swapping the operands, slightly
different sets of HLL-like control structures).  The biggest
difference, syntactically, between HLA and MASM is in the
declaration section.  HLA uses Pascal-like and C-like declarations
(e.g.,   "i:int32;") whereas MASM uses statements like
"i dword ?".  Semantically, of course, there is no difference between
these two, but those who are familiar with HLLs find the former easier
to digest.  Since declarations have little or nothing to do with machine
code, the choice of declaration syntax is not a deciding factor in
the definition of "assembly language."

Don't get me wrong;  I'm not trying to convince you that you need to
switch over to HLA.  Within a month after HLA's appearance I realized
that some people are forever stuck with the A86 mentality and can't
handle an "assembly language" that attempts to save them some programming
effort.  More power to these folks.  They've got A(3)86, they've got NASM.
They're happy.  Some of us, however, don't really care if MASM swaps
a MOV instruction for LEA or if it automatically shortens jump lengths
for us.  We prefer an assembler to automatically choose displacement
sizes without having to be explicitly told the size in the source file.
Heck, a good number of us would be happy as clams if the assembler
actually optimized those sections of code we weren't paying close
attention to (e.g., rearrange instructions, eliminate dead code, etc.).
Whether or not you would consider such a translator an "assembler"
is really irrelevant.  It's a tool.  And a damned useful one to a lot of
people.  Nit picking about whether it's an "assembler" or not is
pointless.

Since people have varying opinions about what an "assembler"
is, let me offer my opinion.  I'm sure this will start a nice long
heated thread about what is and what is not an "assembler," but
I think that putting forth my definition of an "assembler" is a good
idea right now because so many people are confused about what
HLA really is.

First, a history lesson (my memory and knowledge is spotty here,
so I welcome any corrections or elaborations):

Originally (circa 1950's) an "assembler" was a translator that took
statements from a source file and translated them, one-for-one, into
machine language instructions.  A lot of people today still subscribe
to this definition (this is what I refer to as the "A86 mentality").

However, this definition really disappeared when the first macro
assemblers appeared in the early to middle 60's (actually, I don't
know the date of the first macro assembler, but I know that they
were prevalent on mainframes around the middle 60's;  if someone
has a reference on the first macro assembler, I'd love to get it).

In the 70's, the macro assembler was the pre{*filter*} tool.  The
principle feature of these tools ...

read more »



Mon, 21 Jul 2003 02:31:11 GMT  
 High Level ASM and Low Level ASM


Quote:
> Whats the difference between high level and low level Assembly?

Well, if this is a general question, the difference between the two
is whether you're willing to use the HLL-like control statements
in MASM, TASM, HLA, etc.  If you use statements like
.IF (MASM/TASM) or IF (HLA) then you're writing high level
assembly.  If you avoid these statements, then you're using low-level
assembly.  Now some might argue that you can get to a lower-level
still by avoiding assemblers that automatically compute displacement
sizes and stuff like this for you, but if you're willing to subscribe
to this, then we can get even lower level still by supplying machine
opcodes to DB statements.

Like so many other things in life, high-level vs. low-level is not
black and white, but a wide range of grays.  Basically, the less
an assembler does automatically for you, the lower-level that
assembler is;  the more the assembler does for you (e.g.,
supplying proper sized displacements automatically), the
higher-level the assembler.

As for the term "high level assembly language" (not to be confused
with HLA), I'd suggest that any assembler that provides HLL-like
control statements as part of the language (versus a macro package)
is a high level assembler.  At this point this would include at least
MASM, TASM, and HLA.  There may be others but I am not
aware of them.  The "low-level assemblers" would be those that
do not provides these control statements.  Of course, within any
one group, the assemblers/compilers are not equivalent.  For example,
I'd bet that NASM is "higher level" than A86 and Gas is "higher
level" than NASM, even though they are all low-level assemblers.
At the high level end, TASM is higher level than MASM and HLA
is higher level than TASM.
Randy Hyde



Mon, 21 Jul 2003 02:39:21 GMT  
 High Level ASM and Low Level ASM


   >  [...snip...]  [...snip...]  [...snip...]
   >
   >By any reasonable, modern, definition of "assembly language,"
   >HLA's language is an "assembly language."

Heh!  Whoa, big fella! <g>

The tone of the message to which you were replying was that of
tongue-planted-firmly-in-cheek.  The copious '(tm)'s and the
'unmotivated skulls-full-of-mush' were a tip-off. :)



Mon, 21 Jul 2003 05:49:07 GMT  
 High Level ASM and Low Level ASM


Quote:


>    >  [...snip...]  [...snip...]  [...snip...]

>    >By any reasonable, modern, definition of "assembly language,"
>    >HLA's language is an "assembly language."

> Heh!  Whoa, big fella! <g>

> The tone of the message to which you were replying was that of
> tongue-planted-firmly-in-cheek.  The copious '(tm)'s and the
> 'unmotivated skulls-full-of-mush' were a tip-off. :)

True perhaps, but keep in mind that a lot of beginners read this
newsgroup and I have to be vigilant about keeping misconceptions
about this program from destroying it.  It's really amazing how
some negative misinformation in a public forum can wind up being
treated as fact.  I realize that a lot of it is all in good fun and
all, but there are a lot of people who can benefit from HLA and
I'd hate to them turned off by such discussions.  That's why I
vigorously defend all this stuff.  Once in a while someone hits
on a real problem with HLA;  defense of such problems (e.g.,
"why don't you support STDCALL?" is a bit more work and
requires modifications to the compiler.  Other comments just
require an appropriate (or inappropriate in some people's opinions)
reply to the newsgroup.  This one fell into the latter category.
Randy Hyde


Mon, 21 Jul 2003 07:34:45 GMT  
 High Level ASM and Low Level ASM
On Wed, 31 Jan 2001 10:31:11 -0800, "Randall Hyde"

<snip>

Quote:
>Perhaps an IBM (360/370/etc) assembly programmer can
>explain why IBM called their product HLASM;  personally,
>I could find nothing high level at all about it.

I never heard of the name 'HLASM' during the period that I worked on
360 assembler. (1970-1975)  It was always referred to as 'ASMF' for
the F level version, or 'ASMH' for the H level.  There was an 'ASMG',
but that came from Waterloo, not IBM.  About the only high level thing
that I can think of is the macro facility.  The entire SYSGEN
configuration process was one massive set of macros, which either
generated code, or control cards for the rest of the process.

<big snip>

I did look at 'HLA', however it reminded me too much of 'PL360'.  
But, then, I have been an assembly programmer since the 1401 days.

I can't seem to cope with these in between languages.  Either I want
to get into the bits & bytes, or back off far enough to not really
care how the work gets done.  

--
Arargh (at enteract dot com)    http://www.arargh.com



Mon, 21 Jul 2003 07:47:11 GMT  
 High Level ASM and Low Level ASM

Quote:

> Whats the difference between high level and low level Assembly?

I have a different distinction between high- & low-level ASM:

High-level assembly involves calling libraries to do all IO
(call printf), while lower levels will call the OS directly
(int 21h), BIOS functions (int13h), or direct hardware
manipulation (in/out, mov B800:0,7020h).

The lower levels hope to be faster and are less portable
between different OSes on the same architecture.

-- Robert  "You have to play the hand you are dealt in Silicon."



Mon, 21 Jul 2003 12:55:17 GMT  
 High Level ASM and Low Level ASM

Quote:


> > Whats the difference between high level and low level Assembly?

> Well, if this is a general question, the difference between the two
> is whether you're willing to use the HLL-like control statements
> in MASM, TASM, HLA, etc.  If you use statements like
> .IF (MASM/TASM) or IF (HLA) then you're writing high level
> assembly.  If you avoid these statements, then you're using low-level
> assembly.  Now some might argue that you can get to a lower-level
> still by avoiding assemblers that automatically compute displacement
> sizes and stuff like this for you, but if you're willing to subscribe
> to this, then we can get even lower level still by supplying machine
> opcodes to DB statements.

Why stop there? Just knock open Notepad and make use of Alt-gr plus keypad
number sequence to enter things a byte at a time...or is that still too high
level for some people? How about a little utility that lets you tap in each
0 and 1 in turn to make up your file (like one of those telegraph morse code
machines)...

No, wait...the file system is too "high level", isn't it? Ok, then we need a
special piece of hardware that lets you manually control magnetic fields on
your disk (or a "laser-surgery"-style piece of kit for CDs)...

Wait a minute...I've got it...let's junk all this "high-level" hardware
altogether and use a quill and ink pot with some home-made parchment...no,
my mistake...English is far, far too "high-level", so s{*filter*}the idea of
writing things down...I suppose we should just "uugh" at each other
caveman-style...now that is sufficiently low-level, I think...well, unless
you can work out a way for us to regress into ameobas again...that just
might work...

[ *jumps on soapbox* And, yes, this _is_ a "straw man", apparently...but,
Mr.Philosophy 101 (cross-refencing a different post for those who're
wondering...I'm hoping he reads through all the posts in here and catches
this ;), I've said on many occasions: "I'm a heretic"...I really don't care
that this does not fit the official textbook method of philosophical
debate...I mean, if you can't handle people who think, talk and reason
differently from you then, bluntly, your course was _completely pointless_,
except to debate amongst other Philosophy 101ers (as usual, we seem to have
"private members' club" jargon and mentality here...I'm NOT
impressed...computing is bad enough for this sort of thing, without more BS
thrown onto the pile)...and maybe you're ok with the idea of standardising
people's thoughts to a textbook standard (ISO 1234-5678..."how to think and
what you should think when: the correct way") but this is plainly _vile_ to
me...I consider it almost the worst crime that could ever be performed
(somewhere just below "genocide" and "publishing Micheal Bolton CDs"
;)...sorry...that's the way it is with me...

Maybe you only consider slavery and death in a strictly corporeal sense but,
personally, I consider mental slavery and death as similar crimes....worse
even, as you can hide this away for decades/centuries/millenia and no-one
would ever know until a heretic speaks out...I'm going to be crucified
either way, so, I figure, why the hell not just speak my mind?

My "straw men" illustrate a basic flaw (or flaws) in the underlying
principles by clearly showing that a principle will break down when taken
toward the extremes...if a principle cannot be extended to the extremes,
then it is _NOT_ a principle, by definition...priniciples should be as
context-free as is possible or they lose their entire purpose...so, if your
philosophy course taught you that principles make for bad philosophy or
something then I have to completely disagree...to me, they are its very
foundation...and you can quote me as much "my professor has many
qualifications and honours in this field" as you like...he's human...he got
it wrong...as we all can and do...*end of soapbox* ;) ]

Quote:
> Like so many other things in life, high-level vs. low-level is not
> black and white, but a wide range of grays.  Basically, the less
> an assembler does automatically for you, the lower-level that
> assembler is;  the more the assembler does for you (e.g.,
> supplying proper sized displacements automatically), the
> higher-level the assembler.

Agreed; Which is why I've often stated that labels are labels...be careful
not to read anything extra into them...the human mind uses them to be able
to think (nature of the way our minds function and no other real reason
beyond that)...in _reality_, labels just don't exist...anywhere for
anything...everything is pretty much blurred fuzzy logic (to give it a
label...hehehehe ;)...

Obviously, we have to quibble over the semantics of labels to get our
thoughts across to other people but the problem I often see is that people
start to actually believe that reality fits our labels...it doesn't...we're
supposed to fit our labels around it...because we have power over our
language and not reality (well, in a generic sense...we do have power of
this "false reality" we've built around us...with houses, jobs, money,
marriage, language, etc. (all man-made...actually, have a quick look around
the room you're in and look for something that hasn't been man-made or
processed...for me, I see one thing, an apple I'm going to eat once I've
finished up this post ;)...but this is _so_ established now, it _is_ reality
:)...

So, I agree whole-heartedly, nature's fashion is that "grey is the new black
(and white)"...lol ;)

Quote:
> As for the term "high level assembly language" (not to be confused
> with HLA), I'd suggest that any assembler that provides HLL-like
> control statements as part of the language (versus a macro package)
> is a high level assembler.  At this point this would include at least
> MASM, TASM, and HLA.  There may be others but I am not
> aware of them.

Oh...now that is interesting (well, to me, anyway ;)...the "BethTool" will
not provide any HLL-like control statements into the language but will be
able to easily accomplish the same thing...the syntax is basically
macro-heaven (extremes are my thing ;)...so, this makes the "BethTool" a
low-level assembler, eh? Ok...if that's what it'll be, then that's what
it'll be...but when you see a "BethTool" program, you'll find it hard to
believe, I'm betting...lol ;)

Quote:
> The "low-level assemblers" would be those that
> do not provides these control statements.  Of course, within any
> one group, the assemblers/compilers are not equivalent.  For example,
> I'd bet that NASM is "higher level" than A86 and Gas is "higher
> level" than NASM, even though they are all low-level assemblers.
> At the high level end, TASM is higher level than MASM and HLA
> is higher level than TASM.

This is the irony here...because the "BethTool" is in the stratosphere next
to MASM/TASM but, by the definitions so far given, its firmly a low-level
assembler as well...but that is _very good_ indeed...not a problem at
all...I wanted it to be a "multi-level language" rather than high or low...I
wanted it to be different and not an imposter of something else (well, if
its the same thing then its already been done...as people keep challenging
me with, "no sense re-inventing the wheel" ;)...so your definitions here are
just confirming that my designs do indeed conform with your definitions
too...that's kuhl...thanks for the confirmation (even though you didn't
intend to do that ;)...

Sorry...I'm sort of thinking aloud here...no real specific point to make...

Beth :)



Mon, 21 Jul 2003 13:03:57 GMT  
 High Level ASM and Low Level ASM

Quote:


> >    >  [...snip...]  [...snip...]  [...snip...]

> >    >By any reasonable, modern, definition of "assembly language,"
> >    >HLA's language is an "assembly language."

> > Heh!  Whoa, big fella! <g>

> > The tone of the message to which you were replying was that of
> > tongue-planted-firmly-in-cheek.  The copious '(tm)'s and the
> > 'unmotivated skulls-full-of-mush' were a tip-off. :)

> True perhaps, but keep in mind that a lot of beginners read this
> newsgroup and I have to be vigilant about keeping misconceptions
> about this program from destroying it.  It's really amazing how
> some negative misinformation in a public forum can wind up being
> treated as fact.  I realize that a lot of it is all in good fun and
> all, but there are a lot of people who can benefit from HLA and
> I'd hate to them turned off by such discussions.  That's why I
> vigorously defend all this stuff.  Once in a while someone hits
> on a real problem with HLA;  defense of such problems (e.g.,
> "why don't you support STDCALL?" is a bit more work and
> requires modifications to the compiler.  Other comments just
> require an appropriate (or inappropriate in some people's opinions)
> reply to the newsgroup.  This one fell into the latter category.
> Randy Hyde

Uh oh!!! I'm in for a very rough ride with the "BethTool" then...it's heresy
pure and proud...put it this way, current design has _NO_ keywords at all
(and I intend to keep it this way, if I can...so far, we have an operator
count of 6 and I don't envisage more than a few extra :)...then, it does
things "real assemblers" (A86) should never, ever do...

But, unlike other tools, this is because it has (and is still being)
designed from first principles rather than being an imposter for what's
already around with suitable bells and whistles added...

Although, I'll save some of the grief right here and right now...it's _not_
an assembler...if I ever call it that, then it's a freudian slip because I
personally think that would be an appropriate label myself but it wouldn't
fit in with other people's perspective so, because the label seems so
important to other people, where I don't care in the slightest as long as it
does the job that's intended from it, I'll label it for _your_ convenience
:)...it generates object code/executable files, make up your own minds (if
you have one j/k j/k ;)...but, for the record, I'll now name it a
"translator" and avoid the whole "interpreter/compiler/assembler" labelling
debate...

I'm a funny old person, you see...I'm both "A86 mentality" _and_ "HLL
mentality" at the same time...contrary to popular opinion, they are not
completely mutually exclusive...The "BethTool" is a direct attempt to be
"best of both worlds (without losing anything vital) mentality"...if that's
wrong in your book, then I'll wear that "wrong" label with pride...hehehehe
;)

Beth :)



Mon, 21 Jul 2003 12:02:01 GMT  
 High Level ASM and Low Level ASM


Quote:

> Uh oh!!! I'm in for a very rough ride with the "BethTool" then...it's
heresy
> pure and proud...put it this way, current design has _NO_ keywords at all
> (and I intend to keep it this way, if I can...so far, we have an operator
> count of 6 and I don't envisage more than a few extra :)...then, it does
> things "real assemblers" (A86) should never, ever do...

Of course you are.  Anytime you create something that requires
people to change the way they normally do things you're going to
get lots of complaints from people who don't want to change.

However, despite my vigorous defense of HLA, I enjoy these
sparing matches and would be sorely disappointed if they all
faded away.  After all, immediately after unabashed praise,
criticism of a product (well-founded or not) is the best way
to promote something.  Responding to criticism is a good way
to keep HLA in people's minds :-)  Product promotion of something
like HLA can be done in one of several ways:  announcement of
product availability (e.g., each time a new version of HLA appears
I'll post a quick message in the relevant newsgroups), responding
to questions people have (whether or not they are questions about
HLA;  e.g., if someone asks for the "integer to string representation
algorithm" I can provide an HLA solution), or an unabashed
adverti{*filter*}t for the product (i.e., spamming the newsgroup).
I get accused of overly promoting HLA, but you will notice that
I never resort to this last approach;  I typically use the second
scheme above.  The worst thing that can happen to a product
like HLA is for people to forget all about it.  As long as someone
is willing to complain about it, I figure I've got the responsibility
to defend (and promote) HLA at that point :-)  So, Beth,
"Learn from the Master!"  :-)

BTW, this is really good practice.  My goal for the past 20 years
has been to design an all-purpose HLL.  When I first started
to work on HLA I had to decide between working on an assembler
or the HLL.  I chose HLA because it was of immediate practical
value.  Sometime after I get done with HLA v2.0 I will return to
 that project.  Now if you think that "A86 Mentality" programmers
have a problem with HLA, wait until you see how "C/C++ (or
fill in your favorite HLL) Mentality Programmers" deal with a
new HLL.  It will be brutal.  So this whole process is good
exercise in preparation for dealing with those comments.

Quote:

> But, unlike other tools, this is because it has (and is still being)
> designed from first principles rather than being an imposter for what's
> already around with suitable bells and whistles added...

That's what makes it interesting to me.
Of course, those who follow the A86/NASM religion will
find lots to complain about.

Quote:

> Although, I'll save some of the grief right here and right now...it's
_not_
> an assembler...if I ever call it that, then it's a freudian slip because I
> personally think that would be an appropriate label myself but it wouldn't
> fit in with other people's perspective so, because the label seems so
> important to other people, where I don't care in the slightest as long as
it
> does the job that's intended from it, I'll label it for _your_ convenience
> :)...it generates object code/executable files, make up your own minds (if
> you have one j/k j/k ;)...but, for the record, I'll now name it a
> "translator" and avoid the whole "interpreter/compiler/assembler"
labelling
> debate...

I find the whole labelling issue pointless.
It's like the arguments over "true multitasking" versus "cooperative
multitasking" of a decade ago.  Most participates in such arguments
are really displaying their ignorance of well-established terms in Computer
Science rather than demonstrating any particular insights.  My favorite
"buzz word du jour" is "true assembler."  I really love how people have
moved MASM out of the "true assembler" category even though it does
everything that it used to do back in the days that there was no question
it was a "true assembler."  Of course, I'd really like to know what a
"pseudo-assembler,"  "false assembler,"  or "faux assembler" would
be to someone who pushes this term (HLA, of course, is currently
a compiler and I've never promoted it as anything else, so I'll avoid
such distinctions for my own language).

Quote:

> I'm a funny old person, you see...I'm both "A86 mentality" _and_ "HLL
> mentality" at the same time...contrary to popular opinion, they are not
> completely mutually exclusive...The "BethTool" is a direct attempt to be
> "best of both worlds (without losing anything vital) mentality"...if
that's
> wrong in your book, then I'll wear that "wrong" label with
pride...hehehehe
> ;)

Actually, IMHO, the "A86 Mentality" and the "HLL Mentality" are not
disjoint sets.  My usage should be a little more clear to suggest that
"HLL Mentality" is a superset of "A86 Mentality."  By that, I mean that
those with the "HLL Mentality" are willing to accept extensions to
bare ("low-level") assembly language like .IF and .WHILE whereas those
with the "A86 Mentality" are not willing to accept such extensions.
Both groups are assembly language programmers  and I hope I don't
give the impression that "HLL Mentality" suggests that the person
would rather work in a HLL.  Only that such persons have reached
a certain "software engineering maturity level" that they realize that
you don't have to count every cycle and every byte on every instruction
in an assembly language program.  So by your admission above, you
are squarely in the "HLL Mentality" group.
Randy Hyde


Tue, 22 Jul 2003 02:58:07 GMT  
 High Level ASM and Low Level ASM


Quote:
> I never heard of the name 'HLASM' during the period that I worked on
> 360 assembler. (1970-1975)  It was always referred to as 'ASMF' for
> the F level version, or 'ASMH' for the H level.  There was an 'ASMG',
> but that came from Waterloo, not IBM.  About the only high level thing
> that I can think of is the macro facility.  The entire SYSGEN
> configuration process was one massive set of macros, which either
> generated code, or control cards for the rest of the process.

I believe the Web Page Documentation I found that discussed HLASM
was dated 1984.  So that would explain this.

Quote:

> <big snip>

> I did look at 'HLA', however it reminded me too much of 'PL360'.
> But, then, I have been an assembly programmer since the 1401 days.

Definitely the compile-time language has borrowed (by accident, if
not directly) several features from the PL/I macro system.
Obviously C's macro preprocessor borrowed a tiny bit from PL/I's
macro system (accidentally or otherwise), too bad it didn't borrow a
whole lot more.

As for PL360 and other intermediate language (PL/M, etc.), HLA
does have one big difference - those languages mix HLL control
structures with some low-level sequences (calculations).  HLA, like
MASM, doesn't require the use of the HLL-like control structures.
HLA, like MASM, lets you write code at a mid-level language level,
but it doesn't force this upon you like PL/M.

Quote:

> I can't seem to cope with these in between languages.  Either I want
> to get into the bits & bytes, or back off far enough to not really
> care how the work gets done.

Personally, I'd love to have one single language that spans the
gulf between VHLL and VLLL (e.g., machine code) so that
I can work in whatever paradigm is appropriate for the task
at hand.  HLA certainly is not this language since it spans from
LLL to MLL.  Someday when I'm happy with HLA I'll have
to start on that other language.

In your case, though, I would have to ask why you feel it necessary
to use a different tool for each application.  Why shouldn't you
be able to use the same translator to process bits and bytes that
you use to manipulate complex, very-high-level, objects?
Randy Hyde



Tue, 22 Jul 2003 03:07:42 GMT  
 High Level ASM and Low Level ASM


Quote:

> Why stop there? Just knock open Notepad and make use of Alt-gr plus keypad
> number sequence to enter things a byte at a time...or is that still too
high
> level for some people? How about a little utility that lets you tap in
each
> 0 and 1 in turn to make up your file (like one of those telegraph morse
code
> machines)...

How about toggle switches and panel lights?
"Real Programmers" could easily toggle in their "tic-tac-toe"
programs from the front panel :-)

Quote:

> Agreed; Which is why I've often stated that labels are labels...be careful
> not to read anything extra into them...the human mind uses them to be able
> to think (nature of the way our minds function and no other real reason
> beyond that)...in _reality_, labels just don't exist...anywhere for
> anything...everything is pretty much blurred fuzzy logic (to give it a
> label...hehehehe ;)...

I also agree with your exposition.
However, some people take a deeply religious view
of certain labels and will waste a considerable amount of time
(yours and mine) trying to argue that one label is not particularly
appropriate.  My goal here is to throw out my definitions so people
will at least understand where I'm coming from rather than having
orthogonal arguments with them all the time because we're using
similar terms for different concepts.  As for the "basic principles"
issue, all these products (HLA included) are assemblers.  Violating
basic principles is done to appease the masses who've been taught
a very provincial definition of the term.

Quote:

> Obviously, we have to quibble over the semantics of labels to get our
> thoughts across to other people but the problem I often see is that people
> start to actually believe that reality fits our labels...it
doesn't...we're
> supposed to fit our labels around it...because we have power over our
> language and not reality (well, in a generic sense...we do have power of
> this "false reality" we've built around us...with houses, jobs, money,
> marriage, language, etc. (all man-made...actually, have a quick look
around
> the room you're in and look for something that hasn't been man-made or
> processed...for me, I see one thing, an apple I'm going to eat once I've
> finished up this post ;)...but this is _so_ established now, it _is_
reality
> :)...

OTOH, we do need to market our products to an acceptable target
audience.  If I were God and could simply state "this is an assembler"
and no one would question my proclaimation, I would do so.  However,
to produce a product like HLA that offends some people's usage of
the term is dangerous.  You'll notice that I call HLA a compiler yet
I still get a lot of people {*filter*}ing about the fact that I have no right
to call it an assembler.  Imagine the grief I'd have if I'd called it an
assembler and was defending the use of that term!  Yes, this is all
man-made reality, and that "reality field" often extends no more than
about one inch beyond the poster's nose (mine, your's, and everyone
else).  The only solution I found to deal with reality distortion
(mine or someone else's, depending on your perspective I guess) is
to simply state "here are my definitions for these terms, translate them
as appropriate to your terms."

I still find "true assembler" an amusing term, however.

Quote:
> Oh...now that is interesting (well, to me, anyway ;)...the "BethTool" will
> not provide any HLL-like control statements into the language but will be
> able to easily accomplish the same thing...the syntax is basically
> macro-heaven (extremes are my thing ;)...so, this makes the "BethTool" a
> low-level assembler, eh? Ok...if that's what it'll be, then that's what
> it'll be...but when you see a "BethTool" program, you'll find it hard to
> believe, I'm betting...lol ;)

HLA provides two "mid-level" control structures (JT, jump if true, and JF,
jump if false) from which all the others could be created using HLA's
macro facilities.  Indeed, even these two are superfluous (you can write
a macro, for example, to "compile" an arithmetic expression to machine
code and use this as the basis for your boolean expressions in the
HLL-like control structures).  Therefore, one could argue that the
HLL-like control structures in the HLA language are superfluous
since one can easily (well, at least it's possible to) construct HLA macros
to implement all these high level control structures.

I chose to implement these directly in the language rather than as macro
libraries for three reasons:

(1) Compile-time efficiency: the compiler is faster than the macro
processor and having the compiler process these statements reduces
the compile time.

(2) Robustness: the compiler can do error recovery more easily.

(3) Run-time efficiency: it's easier to generate better code by the compiler
(particularly when taking point (1) into account).

Quote:

> This is the irony here...because the "BethTool" is in the stratosphere
next
> to MASM/TASM but, by the definitions so far given, its firmly a low-level
> assembler as well...but that is _very good_ indeed...not a problem at
> all...I wanted it to be a "multi-level language" rather than high or
low...I
> wanted it to be different and not an imposter of something else (well, if
> its the same thing then its already been done...as people keep challenging
> me with, "no sense re-inventing the wheel" ;)...so your definitions here
are
> just confirming that my designs do indeed conform with your definitions
> too...that's kuhl...thanks for the confirmation (even though you didn't
> intend to do that ;)...

Multi-paradigm support is the "holy grail" of good language design.
Definitely it is something you want to pursue with your tool, detractors
be damned!  A good language is one that lets the programmer state their
algorithms in a form that is convenient and readable for the problem at hand
to be solved.  If that means that the programmer needs to specify the
exact opcodes to be used, then the language must support this;  if
it means that the programmer should be able to use set notation to
specify the algorithm, well, the language should support that, as well.

Of course, no language to date has spanned the gulf between
VLLL (very low level language) and VHLL (very high level language)
and your translator doesn't sound like it will, either.  However, a
tool that spans a wide range of grays is far better than a monochromatic
tool.

Without question the magic word you've used in portions of this
post (and other posts) is "macros".  The easiest way to ensure
that your tool will satisfy the widest range of applications possible
is to build in the ability to extend the language.  Macros provide
one way to do this.  If you haven't taken a look at HLA's
macro facilities, I would strongly suggest that you read the
chapters on the HLA Compile-Time Language, Macros,
and Domain Specific Languages in "The Art of Assembly
Language Programming/Win32 Edition".  HLA's ability
to create DSLs (Domain Specific Languages) is HLA's
key to language extension.  Although HLA itself spans
the gulf between LLLs (low level languages) and
MLLs (medium level languages), HLA's macro facilities
let the user develop VHLL constructs.  HLA's pattern
matching library is a good example of a VHLL
"mini-language" (DSL) created using HLA's macro
facilities.  Someday, as time permits, I intend to
add SQL/database capabilities, list processing
(ala LISP) and other VHLL-like constructs using
HLA's compile-time language and macro facilities.

While HLA doesn't have the most powerful macro
facilities imaginable, it does have the most powerful
macro facilities I've seen in an assembler.  You'd not
be making a mistake to study HLA's macros to get
some ideas for your own tool.  (Incidentally, I *have*
imagined a more powerful macro system.  I once
wrote a paper for a USENIX conference suggesting
an improvement to the C/C++ macro preprocessor
that exploited all I'd learned from HLA plus a
bunch of other stuff I'd thought up.  The paper was
roundly criticized and rejected because the reviewers
felt it was important to minimize the use of macros
in C/C++ rather than provide programmers with
a longer piece of rope with which they could hang
themselves).

Quote:

> Sorry...I'm sort of thinking aloud here...no real specific point to
make...

The points are:
(1) It's a shame we have to constantly defend the use of terms
like "assembler".  I should be able to call HLA an assembler
and not have to deal with a flood of nit-picking posts.  Calling
HLA an assembler would be a good thing because some instructors
searching the net for an assembler for their course would locate
HLA a bit easier that way.  However, because of strongly-held
(religious) convictions, I must use the term "compiler" or suffer
the constant wrath of everyone who disagrees with my use
of the term (e.g., look at the abuse I take even though I call
it a compiler).

(2) We can identify two general classes of assembly language
programs: low-level assembly programs and high level assembly
programs.  Again, there is not a clear dividing line between these
two types of programs (e.g., a 10,000 line low-level assembly
program that just happens to use a single IF statement isn't
automatically a "high level assembly program."  Nor is a
high level assembly program that happens to force the
displacement size on a couple of instructions automatically
a low-level assembly program).  "Purists" work only in
low level assembly;  those just wanting to get the job done
in a fast, maintainable, manner will use whatever tools their
translator provides.

(3) BethTool will be extensible via macros, but will require
the programmer to provide all higher level extensions
(presumably, these could also be provided by a library
module in much the same way HLA adds a SWITCH/CASE
statement to the language using macros).

(4) Your design fits within my definitions.  So thus far my
definitions ...

read more »



Tue, 22 Jul 2003 03:53:28 GMT  
 
 [ 29 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Using high level objects from ASM

2. asm and high-level linking, stack problem, please help

3. Using high level objects from ASM

4. Q: ASM to high-level language translators ??

5. Lowest level asm

6. Really Low Low Low Level Stuff.

7. GUI-driven linux asm level debugger?

8. GUI-driven linux asm level debugger?

9. Byte-level to Bit-level Boolean Encoding

10. Migrating IBM COBOL from old levels to newer levels

11. Group level move vs sub-group level move.

12. system level or chip level text file

 

 
Powered by phpBB® Forum Software