Re: HLA suggestions

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 10/30/03 

Date: Thu, 30 Oct 2003 02:00:40 -0000

Randy wrote:
> T.M.Sommers wrote:
> > 3) Now the questions: What do you think of having HLA add
debugging
> > information? I'm not sure how hard that would be, espcially for
> > Windows, but it would have obvious advantages.
>
> For symbolic information, you can do this (well, sort of) under
Windows
> today. Just use the "-aZi -aZf -lDEBUG -lDEBUGTYPE:COFF" to the HLA
> command line and it will embed symbolic information in the
executable. Works
> great with OllyDbg.
>
> Now *source* debugging info is another problem altogether. I don't
have
> a clue how you can do this under Windows (is there some way to emit
> statements in MASM that tell the debugger to look at line XXXX in
file
> YYYY.HLA?). Under *NIX this is a whole lot easier.

It's got to be possible...with Borland C++, if you write C / C++ code
then compile to assembler with debugging enabled, it spits out
"?debug" directives which magically insert debugging
information...TASM recognises these and assembles in the relevent
debugging information...there's a "?debug" for specifying the source
filename and then another type of "?debug L xxx" is put in the
relevent places to denote where each source line starts with respect
to the ASM code...

I don't have MSVC++ but does it use - or could it be coaxed to use - a
similar system perhaps? Because, as above with Borland C++ and TASM,
there's really got to be some way for HLLs like C++ to be able to
insert the source line information into the output, even when you
select the "compile to ASM" option...it's worth a look,
anyway...compile some VC++ code to ASM with debugging stuff fully
enabled and see if it takes a similar approach to Borland C++ / TASM
in having a bunch of (undocumented) directives which are specifically
for adding debugging information in ASM files...

Note, this facility might not be mentioned in the documentation or
anything because Borland don't go to any lengths to explain their
"?debug" stuff either...although, it's easy enough to work out the
basic stuff for specifying filenames and line numbers by compiling a
few C++ programs to ASM and seeing what it spits out...

Such source-level debugging _will_ be possible with TASM using these
"?debug" directives because that's basically how Borland C++ manages
to include this stuff itself...and it's quite possible that MSVC++
uses a similar method for the "compile to ASM / assemble ASM to EXE
(with full debugging)" route too...I just don't have that to be able
to check it out myself...might require some creative playing around
and stuff because it's not directly documentated or whatever...

> OTOH, symbolic debugging info is planned for HLA v2.0.
> However, HLA v2.0 is quickly becoming the king of vaporware
> as I keep getting involved in book projects :-(.

Oh dear :(

Anyway, I'm really posting to offer my own suggestion about the
directory layout business but spotting the above to mention what I've
seen Borland C++ and TASM do for source-level debugging...if something
like that is also employed by VC++ to get MASM to include debugging
information from a "compile to ASM" command then you can simply employ
the same trick that VC++ uses to "coax" MASM to include C++
source-level stuff to work with HLA...that is, presuming that VC++
takes the same or similar approach to BC++ on this, which it might
not...I don't own a copy to verify that, I'm afraid...

Nevertheless, to the actual point I wanted to make...with the
"include" directory, you should include the "stdlib" include files in
that directory "as is"...but that there could be "Win32" and "Linux"
directories inside "include", which contain the OS-specific
stuff...this is a "neatness" thing and keeps them clearly
separate...but also serves to easily make the difference between which
include files are "OS neutral" and which aren't...because to include
the "stdlib.hhf", you'd just use '#includeOnce("stdlib.hhf")', as per
normal...but including '#includeOnce("win32\w.hhf")' means you have to
type out the "specificness" of "Win32" or "Linux"...so there's no
chance of people confusing up their "specific" and "generic" include
files..."portability" in the ASM world is a somewhat unique novelty
that making the distinction clear and _how_ "stdlib" manages to be
portable where the Windows include file isn't and all that sort of
thing is probably something to at least make crystal clear to
beginners...

Actually, in this vein, if you're going to have specific Windows
header files for the "Windows programming in ASM" book thingy you're
working on, then have "stdlib" use those Windows header files
directly...you know, layer one on top of the other because then the
library source code makes perfectly clear to everyone looking over it
how the "portability" thing is actually working...the whole
"indirection" thing of passing it through a "layer" with a uniform
interface, where the "nitty-gritty" goes on in a very "specific" way
underneath the hood...

HLLs have for long enough left a surprising amount of people with the
perception that what they do for "portability" is wave a "magic wand"
that it almost seems a "duty", in my opinion, for ASM-ites to make it
all clear and expose it all so that the "magic" is at last understood
by everyone...to be exercised at will, as they see fit...yes, in my
case, I'm actually thinking of this in terms of NOT using
"portability" when not beneficial because of my way of thinking...but
it works both ways...it should also be _fully understood_ by our
HLLers learning "the ASM way" how it works so that, yes, they can
choose to _implement_ their own "portability" stuff...

I believe in people being allowed to make their own choices on things
like this...but one _crucial_ ingredient to any sort of "freedom" or
"choice" in any matter is _education_...there is only _one_ type of
"choice" in this world: an _INFORMED_ choice...an "un-informed choice"
is just random stab-in-the-dark guesswork...might as well just roll a
dice to decide, for all the reliability "eenie meanie minee moe" gives
you (no, I have no idea if that's actually how the childish random
choice rhyme is actually spelt but it looks good to me ;)...if you do
not have the information because you do not have the education then
you can't appreciate the "choice" put before you...there is, in
effect, no "choice" when there is no education and no information...

Therefore, it should be made crystal clear _how_ the standard library
achieves its "portability" so that beginners can understand this to
not just manipulate it and choose the right header files but to also
copy the method to make their own "portability libraries" and so forth
too...yes, it's an incredibly easy thing to comprehend and do, in
fact...but no HLL ever makes it clear how it does "portability"...so,
even though it's easy and actually "obvious" once appreciated, it's
this _basic appreciation_ - due to no education in the matter - that
is so often missing...it repeatedly is always referred to in "sacred
tones" as if C was "portable" by the "magic" of some "god of the HLLs"
in return for "holy worship" or something...this sort of attitude is a
denial of education and, thus, a denial of freedom, to my
mind...hence, as you may expect, I loathe such conduct with a
passion...HLA does already "expose" it but it wouldn't hurt, I reckon,
to make it blatantly obvious with a little explanation of how it works
thrown in...better to feel perhaps slightly patronised (though some
won't be because they really didn't know and never worked it out for
themselves ;) than to be caged by enforced ignorance...teaching ASM
itself does this for the CPU...but it also covers OS stuff and other
low-level things so there is a place to also inform about things like
this...in a sense, as you work from HLLs down to ASM, then it would
also be good to include _how_ the "levels" relate to one
another..._how_ this "low-level" ends up being "magic HLL portability"
and that sort of thing...fill in all the gaps in between, to inform,
to educate, to provide freedom and choice :)...

Beth :)

Quantcast