Re: Assembler using Lex/Yacc


T.M. Sommers wrote:
> randyhyde@xxxxxxxxxxxxx wrote:

> >
> > Not really. The *real* work is in the HLA Standard Library. Port the
> > HLA Standard Library (or, at least, certain pieces of it) and HLA v2.0
> > will compile just fine on the target OS.
>
> Because HLA 1.xx already exists, and the languages are
> essentially the same. If HLA 1.xx did not exist, you could not
> simply compile 2.0 on, say, Linux.
>

Duh.
But it's only true for C because the work has already been done for C,
too.


> > A classic example of keeping all the OS-specific code isolated. In HLA
> > v2.0's case, that isolation is in the HLA Standard Library. In this
> > respect, HLA code is portable between OSes for the same reason C code
> > is -- the library is what makes the porting possible.
>
> Not just the C library, but the language itself, is standardized
> and widely implemented.

How many different C compilers do we need for the 80x86 in order to
port a C program to the x86? Keep in mind, we are talking about
portability to OSes here, not to different CPUs. Therefore, all we
really need is *one* C compiler for the x86 and as long as the
OS-specific stuff is partitioned off, it's pretty easy to port the code
to different OSes. The same is true for an assembler. About the only
part that needs to be rewritten is the object code output module. The
same is true for an assembler.



>
> >>You would
> >>need either to be able to cross-compile for the new platform, or
> >>to bootstrap with another language.
> >
> > Of course you would cross-compile for the new platform.
>
> And that was my point. Cross-compiling requires more work than
> just carrying some C source over to a new platform and compiling
> (assuming a C compiler on the new platform (and of course, for a
> really new platform, the C compiler has to be cross-compiled in
> the beginning)).

And how is this any different than for an assembler?


>
> > That's one of the main reasons, for example, that HLA v2.0 will
> > continue to provide the option to emit Gas assembly code (in addition
> > to native object code), it makes it *real* easy to port HLA v2.0 to any
> > platform where Gas runs (which is just about everywhere).
>
> It is only easy because you have already done the work to make it
> possible.

And it's only easy for C compilers because the work has already been
done. What's the point here?

>
> > Of course,
> > once a native object file format module is written (e.g., tweaking the
> > ELF module), then you can cross-compile directly to an executable. But
> > this is standard compiler stuff, no surprises there. You always have to
> > bootstrap the first compiler to a new platform.
>
> You only have to bootstrap if the language is written in itself.
> If it is written in a language already present on the new
> platform, no bootstrapping is required. Which is my point.

But bootstrapping only has to be done *once*. And, having a little bit
of experience in this area, let me suggest that it's not the big deal
you're making it out to be. Once the code is running on the new
platform, then you can use to to compile future versions of the code.
Again. bootstrapping is *not* that big of a deal these days.
Cheers,
Randy Hyde

.

Relevant Pages

  • 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)
  • Re: Delphi to bytecode compiler
    ... >>compability, since Delphi was designed as a compiled language, not as a JIT ... > compiler can still do global optimization, ... solve all their programming problems; ... > the platform independence of that code. ...
    (comp.lang.pascal.delphi.misc)
  • Re: HLA StdLib2 criticism
    ... Assembler" (HLA). ... Can that person call this the "FASM language?" ... but also of course not he can call it an assembler ... Therefore HLC.EXE can't be called a compiler. ...
    (alt.lang.asm)
  • Re: C++ and Delphi
    ... >> Porting assumes that everything keeps working, just on a different platform. ... > for the .NET platform (cross compiler). ... > translate all Delphi/Windows API calls into .NET API calls. ... That is the definition of the language as a common thing between compilers. ...
    (comp.lang.pascal.delphi.misc)
  • Re: OOP and memory management
    ... language I am aware of has support for this. ... Most languages have a tendancy to produce predictable and bit accurate floating ... as dictated by performance/architecture of the platform. ... depends not only on the size of each parameter, but the default compiler ...
    (comp.programming)