Re: HLA v1.93 is now available

On 29 apr, 05:29, "r...@xxxxxxxxxx" <r...@xxxxxxxxxx> wrote:
On Apr 28, 5:23 pm, kistjeb...@xxxxxxxxxx wrote:

From what I've gathered, if he is
going to release HLA v2.xx (the one with its own internal object
code emitter) in Public Domain as well, like he did with HLA V1.xx


That is certainly the plan.


until Fasm got built in and he was forced to comply to the
Fasm license, he has to write the object code emitting part himself.


Actually, I wasn't "forced" to do anything. I *could* have written the
back-end myself. The only problem with that issue is that the time I'd
have spent doing it couldn't have been put to better use doing things
like HLA stdlib v2.0. The bottom line is that had I written my own
back-end for HLA, people would *still* be compiling their HLA source
files to OBJ files, just like they are today. What would be the
benefit of spending the time doing that? Instead, lots of progress has
been made on something that geniunely *is* useful, such as the new
tested and documented HLA stdlib v2.x modules.


Anytime you incorporate software from other sources into your system,
you must abide by the license agreement for that software. Of course
this is the case. Rene realizes this. It's just that he has lost his
big argument about "HLA isn't an assembler because it doesn't contain
an integral back-end", so he has to come up with some new story. I
guess he thinks that claiming the software was stolen is going to get
him somewhere. Obviously, as you've pointed out as a "third party",
no one is buying this nonsense.


But if that turns
out to be the case it would basically mean that, when HLA v2.xx ships,
Hyde has succeeded in writing a full-blown x86 high-level assembler,
leaving the anti-HLA crowd without their most stressed argument.


Actually, that argument has gone away already. The native code
generator is built into HLAPARSE. It doesn't matter *who* wrote it.
The bottom line is that you have a single program that takes source
code in on one side and produces object files as output. No
intermediate disk files, no running a "separate" assembler program to
produce the object file output. The fact that I employed FASM source
code (in a manner completely consistent with its license) is
irrelevant. That's no different than if two people had worked on the
assembler (e.g., NASM) to begin with. The fact that the FASM code
generator is fully integrated with FASM is exactly what has got Rene
so upset: he's left without his most-stressed argument.


Thnx for the reply; clarifies a lot of things for me. But I'm afraid
we're not quite on the same wavelength here. I fully understand that
completing the design of HLA2 and bugfixing first, and leaving the
object code emitter for last would be wisest. HLA v2.xx is going to be
released in PD. The consequence is that the source code for HLA v2.xx
and higher _CANNOT_ contain any code that has been released under a
license that's more restrictive. In practice, that would mean about
every license (including GPL and the Fasm licence) would be
incompatible with HLA, and that Fasm cannot be used as the back end
for HLA v2.xx. The latter would either disprove that HLA v2.xx has its
own object code emitter (incorporating the Fasm module/executable
would set HLA back to the "pass intermediate code to another
assembler" technique), or violate the Fasm licence (incorporating Fasm
source code into HLA source code would make HLA take the Fasm license,
prohibiting release in PD). To put it more directly: you've said that
HLA2 is going to be written in HLA1. My question: is that going to be
a 100% complete rewrite, including the object code emitter, or not?
I'm asking 'cause it would be a shame to throw 10 years of works out
of the window due to an oversight of license differences.

Grtz.

.

Relevant Pages

  • Re: Help me about this question.
    ... manage multiple assemblers in multiple OSen - if you're going to ... it's a big win as I look towards using FASM as a back-end. ... that HLA produces when it generates so many files, ... I actually would have gotten a license from Microsoft to distribute ...
    (alt.lang.asm)
  • Re: Help me about this question.
    ... As HLA really requires nothing more from FASM, ... I'll have to set up a Linux box to test this one of these days. ... Is it a "benefit" to be able to view code that won't assemble? ...
    (alt.lang.asm)
  • Re: Help me about this question.
    ... If you don't think that the FASM ... better source code formatting, then that explains why your source code ... complaining about the quality of the HLA standard library code? ... to compile its own Win32 Equates list, clown. ...
    (alt.lang.asm)
  • Re: HLA v1.90 is now available on Webster
    ... FASM is a good Assembler written by a guy called Thomasz Gritszar. ... FASM's code easier to read than the RosAsm source code, ... HLA is an absurd HLL Pre-Parser ...
    (alt.lang.asm)
  • Re: Help me about this question.
    ... No doubt you *can't*, clown. ... FASM application. ... complaining about the quality of the HLA standard library code? ... niche for people who want an assembler syntax that is similar to NASM ...
    (alt.lang.asm)