Re: HLA StdLib2 criticism


Raedwulf wrote:
randyhyde@xxxxxxxxxxxxx wrote:

Yes, assembly language programmers are notorious for wanting to
"reinvent everything from scratch" on every project. That's why we
don't see too many large assembly projects ever complete. It's why a
product like FRESH didn't quite make it but a product like HIDE *has*
made it.

Actually Fresh didn't quite make it because one of the main developers
John Found , seems to have left the FASM scene (last post on FASM
forums is May 2005). The other main developer decard, has had some
changes in the real world, so....he's been unable to contribute further
as well.
Its not because the structure of Fresh is not sound, it was because it
was a hobbyist project - with the main developers disappearing.

But that's my point exactly. The project was a *lot* of work and the
two main developers had only so much time to spend developing it. The
project was simply too big for them to tackle -- they ran out of time
before they finished the project. Now had they used existing library
code to reduce the amount of effort it would have taken to complete the
project, they might have finished it in their available time. That's
why HIDE has succeeded where FRESH failed -- Sevag was wise enough to
reuse available code (e.g., the RadASM editor stuff), thus reducing the
effort needed to get a working IDE.



HLA, I've said before is nice, but it would be brilliant IMHO, if it
had built-in machine code output.

Exactly how would that make any difference to the typical user of HLA?
HLA's implementation gets thrown out all the time as the reason "HLA is
not an assembler." Yet the internal implementation makes almost no
difference in the language. The end programmer sees the same thing
regardless.


At the moment I think HLA should
rather be called HLAT, as it is more of a translator than an assembler.

Like any other assembler, it can be called a translator. It can be
called a compiler. I can be called lots of things. That doesn't mean
it's not an assembler. An assembler is simply a compiler (translator,
whatever other term you want to use) for an assembly language. HLA is
an assembly language, the HLA compiler translates assembly language
into machine code; ergo, it is an assembler.


However, having said that, maybe you could make use of FASM's DLL
version, modify it into a static object (ooo I feel Betov cringing) ,
so you can just use the FASM engine but link it into HLA, and feed it
the asm straight into the memory to be assembled by the FASM 'module'.

Why would that make any difference? All I would be doing is changing
the format of HLA's internal representation. Why does it matter whether
HLA's internal representation is human-readable? True, it may take a
little bit more *time* to convert that human-readable form into some
other form that the back-end can recognize, but why does it matter?

Let me put it this way: FASM's macro processor is a traditional
pre-processor. That means it accepts text and produces text. You don't
seen anyone griping because an internal format that FASM uses is
human-readable text, do you?

I'm already using FASM (or MASM/Gas/TASM) as the backend of the HLA
system. What difference, which would be valuable to an end user, would
it make whether I wrote more code on the front end to reduce the amount
of code I use on the back end? In the end, they provide HLA source
code to the system, they get object code out. That's all that really
matters. How it gets from point A to point B is really irrelevant.

(Because I'm assuming you generate an external listing? I've not
touched upon HLA for a long time) This would be quicker than creating a
listing?

The amount of time HLA (and the back end) takes to read and write the
intermediate files is almost inconsequential.



Well, I think HLA would get a lot more popularity if it was a
pure-assembler... Just a thought

No really. People aren't anti-HLA because of its implementation. They
are anti-HLA because they've learned some other assembler first and
they see HLA as a threat to their concept of how assembly language
ought to be done. Indeed, only Rene and 'bee tend to make a big deal
of HLA's implementation around here. When HLA v2.0 arrives, and they
can't use that complaint anymore, they'll just switch to something
else.



HLA StdLib2 - Try and fix some of the bugs vid mentioned :)

Of course.
Indeed, I'm fixing a lot more bugs than he has mentioned. As I pointed
out, though, when you've got over 1,000 different functions it's going
to take a bit of time to do. It's not like Vid's bugs were all unknown
or that his list of bugs are the only known bugs in the system. For
example, in the os dependent file I/O module, all the file pointer
functions use 32-bit pointers. Bad, bad, bad. That's on the list of
things to fix. More importantly, there are a ton of undiscovered bugs
in the HLA stdlib. If you look at the v2.0 web page (and download the
code), you'll see that the *biggest* part of this project is the
regression test code that is being written. The regression tests on
the four modules I've completed thus far have turned up a couple dozen
defects that have been in the system all along (it's also turned up a
lot of defects in the new code that is being written). So yes, fixing
bugs is one of the main priorities of the stdlib v2.x series.
Cheers,
Randy Hyde

.

Relevant Pages

  • Re: Rocket Science
    ... >> Also, logically, if MASM is the underlying assembler being used by ... then MASM must always be being run in addition to HLA so ... the MASM or FASM or whatever underlying assembler's speed into its own ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... HLA's implementation gets thrown out all the time as the reason "HLA is ... it's not an assembler. ... Takes source code in human readable form to another source ... I'm fixing a lot more bugs than he has mentioned. ...
    (alt.lang.asm)
  • Re: .EXE -> .ASM -> .EXE
    ... HLA, why would they even come you your forum? ... becoming RosAsm users). ... needs to learn assembly language. ... I do think it would be much more an improvement you write an assembler, ...
    (alt.lang.asm)
  • Re: Questions about the HLA installation...
    ... > HLA, assembler and linker in order - depending on your command line ... Windows98 is probably the 'stablest' Windows ... *and* maintain in bare bones assembler. ... all of it pales in comparsion to his 'adventure' with Iraq. ...
    (alt.lang.asm)
  • Re: HLA StdLib2 criticism
    ... HLC.EXE with an already existing C compiler and calls it HLC system. ... Suppose someone creates a new language and calls it "High Level ... Assembler" (HLA). ...
    (alt.lang.asm)