Re: HLA features

From: Beth (BethStone21_at_hotmail.NOSPICEDHAM.com)
Date: 11/01/03 

Date: Fri, 31 Oct 2003 23:56:54 -0000

Randy wrote:
> Beth wrote:
> > I've not looked at the source...but wouldn't this actually be
quite
> > simple to change? Just alter it from "fprintf(stderr, ...)" to
> > "fprintf(stdout, ...)" or whatever...after all, isn't the "-test"
> > switch already making the change? Just swap around the default
> > "streams" or something ;)...
>
> Actually, the current statements are "fprintf( output, ....);" and I
simply
> assign the FILE* variable output the value of stderr or stdout
depending
> on the presence/absence of the "-test" command line parameter.

Of course...that's how I'd tend to format it too so that it could be
easily changed...but, as I say, I'd not looked at the HLA source code
so this was more a "rough description" of the changes needed...if
you've already prepared things so that all you need do is change one
variable then all to the better :)

> It would be trivial to recompile the HLA.C file (which is a
stand-alone
> program and doesn't require recompiling the entire compiler) do
> change the default behavior.

Well, basically, are you going to do that? Because that's really my
point here...that, yes, there's not much to logically separate
"stdout" from "stderr" (they point to the same place by default
:)...and though you could reasonably think "well, these are error
messages it's spitting out so they should go to 'stderr'", which makes
some sense...this is unfortunately NOT how most tools view things,
expecting everything on "stdout"...so, for practical reasons, it's
actually a lot more useful for it to be coming out on "stdout" for
operators like "|" and ">" to work and other command line utilities to
happily work with the output...then "-test" can just do the reverse,
as it does now, but the defaults are swapped...

Yes, a small trivial little thing...but, as you yourself have noted,
it's in these little details that a "professional" product that users
like resides...although, thinking about it, changing the stream won't
effect RadAsm or something, will it? Or is RadAsm happy to intercept
output whatever it's routed through?

And, while we're on the subject, I've noticed that you've now added
the "response file" stuff to the command line...much
appreciated...except, ummm, it's not quite working...the final
character in the response file gets chopped off (fine if it's just a
carriage return but it might not always be the case ;)...it worked
with just a filename in the file but if other options were put in
there - but without a new line between them - then it looks at the
whole thing as an option and rejects it...also, switching on the "-v"
option, it once produced a very weird display where it output
something like "1: response file" and "-o:omf" over and over again
before just stopping, having done nothing...

It seems to be somewhat "fragile" at the moment...not very "robust" to
odd inputs...but it's great that you've included it...very much
appreciated...so don't get me wrong when I'm forced to say: I look
forward to when it actually works...because, as I noted, I wanted to
see this option included to be able to get it to work with my
IDE...and the particular things it can't handle are exactly what my
IDE spits out (for example, the IDE uses macros to create the contents
of the response file but doesn't put any new lines in it...it's just
like an ordinary command line but just inside a file to allow it to be
really long...and HLA seems to consider this as one long command line
option, as if it can't see the spaces between arguments or
something...and rejects it...that is, it says that
"-w -v -c -p:temp -o:omf" etc. isn't a valid option...well, yes,
_combined_ it is a valid option because it's supposed to be a series
of options...but, oddly, HLA's looking at the entire thing as if it's
just one big option and the spaces weren't there...if this is any help
in diagnosing why it's behaving strangely like this ;)...

> > Which, of course, is probably something me or Randy should have
posted
> > a long time ago to counter the "it's Pascal!" claims...nothing
makes
> > the point better than actual code people can compile to see for
> > themselves...
>
> Actually, the "it's Pascal!" claims help *sell* HLA!
> Most of the people complaining about HLA "not being true assembler"
> have already made up their mind a long time ago; I'm not going to
convince
> them that they should learn HLA. OTOH, a lot of people are
interested
> in HLA because it looks so much like Pascal (or "C wrapper" as a lot
> of people mistakenly call it).
>
> Yep, there's a few individuals who have concerns about learning
> a product that "isn't a real assembler." But they are a small
percentage and
> I'm not going to get 100% of the incoming population to learn HLA
anyway
> (heck, this isn't the problem at all; the big problem to wide
acceptance of
> HLA is the inertia behind the MASM32 project).

Yeah, well...notwithstanding, "it's Pascal!" is inaccurate...it should
be addressed with a more accurate picture of what is going on than to
simply accept it because it's not a bad thing to have people
believe...a "principle" thing, you know? It's not right so it should
be corrected but this shouldn't actually effect those who are looking
at HLA because they think "it's Pascal!"...because, even though it
isn't Pascal, what it is, is close enough to what they want that the
difference doesn't matter...that is, when people come to HLA thinking
along "it's Pascal!" lines, it's not really _Pascal_ that they're
looking for...but something that's about as easy to code with as
Pascal...and HLA mostly reaches that for them...

If you like, an apple isn't an orange...so, rightly, you must call the
apple "an apple" and the orange "an orange"...but when someone's
hungry, they will not care actually in the slightest if it's "an
apple" or "an orange" so long as it's a tasty fruit that they can
eat...it's the same basic rough principle when it's "hungry for
knowledge" rather than for food :)

Regardless, there's no sense lying when there's actually no particular
reason to do so, as the truth isn't in any way harmful to be
stated...especially when, after all, you would not actually want to do
anything so silly as prove Rene correct about "Lies! Swindles!
Sh*t-selling!" and so forth, when there was absolutely no actual good
reason not to just put your hands up and admit what HLA is...because
though it may not be "Pascal!" nor even perhaps "'real' assembly" in
someone's eyes, what it is, is a good, useful and noble thing in its
own right...

To my mind, that's what makes HLA good...the fact that it _isn't_ any
of these things specifically but rather something different that's "in
between" and, thus, is able to work towards a "best of both worlds"
solution...that, in effect, HLA does NOT make a needless "compromise"
just to fit into some arbitrary category of jargon but concentrates on
giving what is actually useful...

Human instinct may generally stray towards automatically presuming
"different" means "bad"...but, often, that instinct has got things
totally backwards and seriously wrong, in fact...fearing change is
understandable...even a sensible thing to do, if it makes you take a
cynical and critical perspective of it before you're willing to adopt
it...that's really what the "we fear change!!" human instinct is
_supposed_ to be all about...to make you _cautious_ about anything
"new" and "different" so that you take the time to review it to see if
it'll actually work and whether it's a good thing for you to follow
it...the problem, though, is that sometimes it kicks in too hard and
ends up paralysing someone from actually adopting what is a good,
useful new method or technology or whatever...the "rabbit in the
headlights" syndrome...

Like going on stage in front of an audience, you _should_ be
nervous...that's a _very good_ thing, as it keeps you concentrated and
focussed...it proves that you actually _give a crap_ about giving a
good performance and not messing up...but this healthy instinct
becomes totally _unhealthy_ when you walk out on stage to the
microphone and - bang! - you're a "rabbit in the headlights" (or
"spotlights" in this particular case ;) just standing there doing and
saying nothing...the fear has paralysed you because you're
over-worrying, over-panicking, to fearful to make even the slightest
movement, lest you get it wrong...and that fear of messing up is
actually your very downfall...the thing that makes you mess
up...worse, realising this as you stand there, you could become _even
more_ paralysed because you know you've messed up and now you're
scared crapless worrying over how you're going to get yourself out of
this mess without making it worse than it already is...it's a
"downward spiral" kind of deal...once you start locking up with fear
paralysis, it makes you even more fearful and prone to lock up even
further...

So, sometimes, whatever your instincts are telling you, you simply
have to disregard them to get yourself out of this "downward
spiral"...when the audience laughs, then laugh along with them
because, sure, you _do_ look stupid...happens to the best of us...no
big deal...hey, crack a joke and just accept your new role as a
comedian...that's a valuable and respectable profession - in fact, an
incredibly difficult and harsh one, constantly working against your
natural instincts not to want to look stupid, that if you can master
it, you're arguably a better performer than most - to have too ;)...

So, fine, if it's a "joke" to some people then just make it a damn
good, intelligently witty "joke", so to speak...craft the very best
"joke" you can think up and then take your bow and do it all again the
next day...that requires, in fact, usually _more talent_ to
master...so it's a perfectly respectable profession and, as always,
"the only thing to fear is fear itself" ;)

> > Although, on this point, I'm _still_ going to complain that HLA is
> > lacking the "count the initialisers" functionality that you can
find
> > in C / C++...you know, where you put "int Integers [] = { 1, 2, 3,
> > 4 };" and then the C / C++ compiler counts up that there's four
> > initialisers and makes "Integers" into a "int [4]" array...this is
> > _ALL_ a "strictly compile-time" thing processed as it reads the
source
> > making not an ounce of difference to the final output...but it has
a
> > _very handy_ use...if you've got any sort of "variable-length
array"
> > then you can "NULL terminate" that array (and any code that reads
from
> > the array looks for a "NULL" value - or some other "invalid" code
you
> > might use to signal the end - and then just stops reading from the
> > array :)...
>
> No, it's not missing.
> I added this feature a couple of versions ago.

Oh, okay...I didn't notice that...the "updates" come thick and fast
with HLA that, oops, I wasn't keeping up with the "latest"
there...apologies...

> > So, one simple solution here - which I've tried to suggest to
Randy
> > would make a great little addition to HLA - is a special syntax
like
> > C's "[] = {};" which says "the size of this array is defined by
how
> > many initialisers we have for the array"...then, you can literally
add
> > and remove rooms without doing anything else (well, other than to
make
> > sure that the links to and from other rooms all make sense and fit
in
> > with the map, of course ;)...a "NULL terminator" isn't needed on
this
> > particular example because the rooms are all pointing to one
another
> > and as long as there's no mistakes in the "links" from room to
room -
> > and the code that processes it - it should be impossible for the
> > player to ever walk "outside" the map...but, for other things,
like
> > "variable-length lists" that need to be processed sequentially
then
> > you can just stick a "NULL" value at the end of the list...exactly
> > like a "NULL terminated character string" (ASCIIZ :), except that
> > we've got a more "exotic" form of "string" here...a "NULL
terminated
> > string of structures" or whatever...though it's usual to think of
> > "string" as something different and "fundamental", it's not
> > really..."characters" are the primitive type, "strings" are really
a
> > more general name of any sort of "vector" of objects ;)...
>
> Well, I don't remember the suggestion, but I added this feature
anyway :-)

Well, I did make the suggestion and you did reply to it at the time,
if I recall correctly...perhaps, then, it was a "subconscious"
thing...or maybe you'd always intended it, anyway...who knows? And,
basically, who cares? As long as it's now been added, that's all that
really counts :)

> > Well, I can be "half smug" on that score because I jumped on the
> > bandwagon first before it was actually "popular" to do so...when,
in
> > fact, it wasn't even really a "bandwagon" because there was no-one
> > else on board...
>
> And I appreciate that.

Ah, you're welcome...but, really, it's just me and the way I am...I
don't take "sides"...or, at least, my "side" is defined by what
appears to be the most correct...not simply because some "cause" or
another has some celebrity or the most people or whatever...I take up
"the cause" when it appears right (I may be mistaken in that, of
course, but I do try my best to get it "right" as far as I can :),
yes...but I don't "join the gang", simply for the sake of joining the
gang...often, this can cause difficulties, I know well, because some
take it as like a "personal" thing...but it's nothing of the
sort...the company I keep is defined by the company I keep...and what
I believe to be correct is defined by what I believe to be
correct...the two can, unfortunately, interfere with each other
sometimes (especially when people _insist_ that they do because
they've chosen to "define themselves" by these things and expect me to
do likewise :)...but I consider the two to be essentially independent
and though it can't always be done - a bit like the proverbial
"business and pleasure" - there's no compulsion to mix them...it's
probably, in fact, even a "healthy" thing NOT to mix them :)

> > Actually, yes, I'd agreed with that...I'm eager to see v2.x but
that's
> > actually from the perspective that I'm presuming it'll sort out a
lot
> > of the smaller HLA problems...the implementation stuff - not
needing
> > another assembler, better error message output (from doing this
stuff
> > itself rather than using Bison), better speed, etc. - should
certainly
> > be fixed with v2.x because of how it'll be created...but, then
again,
> > if v1.x is being extended for eliminating bugs, issues, adding new
> > useful ideas, etc. then as that stuff could contribute to a better
> > v2.x, it's a justifiable - even desirable - postponement...
>
> Don't forget listings :-)

Oh, yes...don't forget listing files! Never forget those listing
files! _Very_ important and everything! ;)

> > Although, I've wondered about that...does the type facilities of
the
> > underlying assembler have to be all that good? What I mean is, if
HLA
> > itself is keeping track of all these things for its own purposes
> > (analysing the HLA source code for "correctness") then doesn't it
and
> > couldn't it use its own typing facilities and the underlying
> > assembler's lack of typing isn't such a problem? Except for the
> > already suggested problem Randy's mentioned about not
automatically
> > "optimising" jumps (which is a different kind of issue, not really
> > related to "typing" of data :)...
>
> At some point (HLA v3, HLA v4?) it would be nice to have a data
> flow analyzer that optionally warns people if they're doing some
> crazy things (e.g., pushes and pops don't match, attempts to access
> FP variables with integer registers, mixing signed and unsigned
values
> in a computation). One has to be careful, though. The warnings can
> get quite annoying if someone is doing all this on purpose. OTOH,
> it is *great* for beginning students.

Well, just make everything "optional" and provide "switches" and so
forth, then it's pretty hard to go wrong...with HLA's "target
audience", these switches may tend to be "on" rather than "off" by
default, to help those beginners...but as long as there's always an
"off" switch, then you cater for everyone's preferences :)...

Just make it as easy "not to do" as it is "to do" and then there can't
really be any great complaints to be made...in fact, here's a nice
little idea which tends to happily cater for all...have a plain text
"configuration file" - HLA.INI - and then have HLA read its "default
settings" out of the file (not out of the registry! Though it's
similar in principle, the registry's "hidden" nature is a horrible
thing ;)...the "HLA.INI" that comes with the package unedited is set
to "beginner" defaults...but the "advanced" user opens it up in
Notepad and changes "Analyse = yes" to "Analyse = no"...

Now, a simple command line switch to turn it "off" is just as valid
and any command line switches would automatically "override" anything
in the ".ini" file...but the ".ini" file allows the user to set the
"defaults" just the _once_ and then HLA is always in "advanced mode"
every time they use it without having to type in anything extra...

Mind you, at the moment, there's not really enough switches and
settings to probably justify taking an approach like this at the
moment...but it's an idea to consider - for _any_ tool, really - when
there's a lot of options and settings, where the "defaults" could
equally be "beginner" or "advanced"...

> > Perhaps I should actually look into the HLA source code...but,
well,
> > the whole "unravelling massive Bison files" stuff puts me off that
> > idea...yes, that's just laziness but justified laziness, I reckon
;)
>
> AAAAAGH!
> Don't do that.
> A few people are looking at the source code right now and
> it's convinced me that I really need to go in and clean up that
> kludge before anyone else looks at it :-).

:)

> > Also, if Randy instead works on v2.x instead of spending lots of
time
[ snip ]
> > assembler's facilities to work it out for HLA...
>
> Actually, one of the main reasons for doing NASM output in
> HLA v1.x is specifically to see the kinds of problems I'll encounter
> *before* doing the code for HLA v2.0 (i.e., use HLA v1.x as
> a prototype). This, plus the ability to port HLA to other OSes is
> one of the main reasons I'm interested in the NASM port.

Ah, of course...I was thinking from "user perspective", not "author
perspective" there...that makes sense..."prototyping" and all that :)

> > So, in many ways, it might make a lot more sense NOT to bother
with
[ snip ]
> > putting "jmp short", "ds:[]", "dword ptr" and stuff like that
> > everywhere ;)...
>
> NASM output is something I can sneak in between other projects.
> HLA v2.0 is a *huge* undertaking. That's one argument for putting
> NASM output in earlier.

Okay...I'm convinced...ah, it was probably just me being impatient to
suggest different, anyway ;)

> > Although, this would delay NASM output...and might even conspire
to
> > making it pointless to attempt, anyway...I'm not totally sure why
> > specifically Randy wants things like MASM and FASM output on v2.x,
> > which'll be a proper assembler itself...although, it won't hurt to
> > have these facilities, other than to take up Randy's time...and,
well,
> > it's his time to spend...plus, Randy's usually a pretty speedy
coder
> > that it probably wouldn't take him all that long to do :)...
>
> Mostly, NASM output depends upon that whole issue of "forward
> equates" and whether I've completely solved that problem in HLA
v1.x.
> Other than that, most of the time would actually be spent *learning*
> NASM.

Actually, on a completely unrelated subject but this has just reminded
me, I tried writing to a code section using HLA and got a lot of error
messages...none of which actually related to what the actual issue
was...HLA doesn't support writes to code sections...now, of course, I
do know that such things are a "bad idea" and "not very good software
engineering" and all that stuff...but should HLA be the one
prohibiting this? Especially if we consider HLA being used for, say,
OS development or maybe embedded stuff...stuff which ain't so
important at the moment, perhaps, but if you're getting more
"advanced" users...well, the point being that beginners will be
putting all their data into their program with "static" data
declarations which put it into the data rather than code section,
anyway...even though it's "bad idea" stuff for beginners, maybe, this
actually naturally would only be something "advanced" users would be
encountering anyway, trying to stuff their data into a code
section...and, as we know, "advanced" users tend not to appreciate
these sorts of things...

Perhaps, instead, you could maybe do a bit like TASM's "check for code
segment overrides in protected mode" switch...or, come to think of it,
something like the ".386" versus ".386p" directives in other
assemblers...that is, by default - for the beginners - this stuff is
signalled by a warning or error or something...and then there could be
a set of switches about relaxing checks / prohibitions on "dangerous"
things to allow it to be done when the "advanced" user specifically
says "yes, this stuff is okay" with an optional switch...so that
writing to code sections or using "priviledged" instructions - which
would generally make Windows blow a fuse unless you've set the section
flags properly or were writing, say, a device driver or something - is
picked up and warned against unless it's been specifically okay'd by
the programmer because they actually _want_ the code to do something
like this...

In fact, that's something else that's in other assemblers that might
also have a place in HLA, now that I pick up on it in passing...the
".386" / ".486" / ".MMX" style of directives...these do get less
useful as time goes on...but could come in handy if someone wants to
specifically write code that should still work on a 486 or one of
those original Pentiums that lacked MMX and that sort of
thing...although, it's actually possibly getting more useful as Intel
and AMD compete with 3DNow! and so forth which aren't necessarily on
each other's chips...so, restricting the available machine
instructions to specific chips has its uses for people who might need
wide "compatibility" to run on older machines or just to make sure
that, though it may run happily on an AMD, it won't blow a fuse on an
Intel...blah-blah-blah...

Of course, I'm waffling on here...you don't have to immediately
include any of these suggestions...perhaps v2.x things...and you
_could_ equally choose to decide that you'd rather mark which
instructions work on which chips in the _documentation_
instead...because as long as there's some way to ensure this stuff,
though a manual way might not be as "convenient" as an automatic
solution, "it'll do for now" ;)

> > Oh, I'm not quite sure what you're talking about here...but would
I be
> > correctly extrapolating from the "externdef" mention that this is
> > about HLA depending on "conditional inclusion"? That is, that it
> > defines the prototypes for a ton of stuff, expecting the linker to
> > correctly ignore anything that actually isn't used...the usual
little
> > attribute of the "externdef" directive?
>
> Originally, whenever HLA included a header file, it emitted an
> "externdef" statement for every external declaration. MASM, of
> course, wouldn't link in the corresponding code unless you actually
> *called* that function. Alas, other assemblers didn't have this
> feature, so I had to manually track which external symbols a program
> uses and only emit "extern" directives for those symbols. Otherwise,
> you wound up linking in the entire HLA Standard Library for
> a short code sequence. Not Good. This feature is pretty much under
> control, now.

Ah, an old problem...okay, cool...just wondering what the topic was,
as this seems to be something discussed on CLAX or whatever, when I
wasn't looking or something :)

> > Yes; In fact, in general, I'd recommend a general policy of more
> > "virtual" directives that don't necessarily generate code and
[ snip ]
> > is a radical different approach to view how a tool should work,
that's
> > true :)...
>
> Templates would be nice, yes.
> That's something I'm thinking about in the v2.0 timeframe.

Well, what I'm talking about is a tool that's _purely_ templates
throughout...but that's not a HLA suggestion or anything...that's just
me and my "alien brain" heading off passed Jupiter, as per normal ;)

Beth :)

Quantcast