Back to home page

DOS ain't dead

Forum index page

Log in | Register

Search:  
Back to the forum
Board view  Mix view

FPC for DOS / FreeDOS (DOSX)

posted by marcov, 13.04.2008, 23:17

> IMO it's absolutely "sane" if I prefer to decide what's to use based on MY
> experience and it would be somewhat "insane" if I take YOURs instead.
Well, it is a pity if this turns in a yes/no contest, so just leave it, and focus on the other subthreads.

(...)
> you should be aware that there is no real
> assembly language "standard" and there's also no clear border where a
> thing is no longer to be called an assembler and "starts" to be a
> compiler.
First, I'm not a compiler expert. However I'm not the first naieve newbie either.

That border is arbitrary and vague indeed, but that doesn't mean there are no differences. The usual is "compile from higher to lower language".

Wikipedia seems to define it that way, and I've seen these discussions get out of hand because the definition of "high" and "low" is discussed ad infinitum.

Stronger, the other way around ("low" to "high") is still a compiler, since it is more than a bit of rewriting, analysis is required. (like very clean C to Java to run it on a JVM on a phone)

And a macro assembler that "compiles" to assembler also fits the definition (and the poor slobs that upload microcode patches to the CPU might argue that about assembler to microcode too). And strictly one could even transcode a lower language to a higher language.

So in general I would conclude it in one word: abstractions built into the system, rather than duck taped on via e.g. preprocessors and macro's. So abstractions in data (data types), program build up (information hiding, separate compilation), flow constructs ("proper" functions, loops etc). Abstraction from the machine too (it was actually one of the main reasons why HLLs developed), but it is not required. Personally I'd value abstract concepts for data, code and program organisation more.

The exact border is still vague, and one can bicker over that for decades, so I won't try, specially with exhibit A: the C language that does way too much with a preprocessor lurking around the corner.

But while one can bicker about the detail level as much as one wants, I think the principle division is fairly clear.

> In other words, some assembler implementations deliberately "forget" the
> types of variables (NASM) and others have rather strong type checking. And
> nothing prevents you to write an assembler which - optionally - also will
> understand CLASS, VIRTUAL, FRIEND, ... and thus support OO directly.
But is it then still an assembler at all? Maybe it then has become a compiler for a language with a bit of assembler here and there?

If you think about it that way, when does the macro handling become a language in its own right, and can the bits of asm in between seen as "inline assembler"?

Such thoughts were initially the motivation for the above definition (without "high" and "low"). Apparantly the difference is when it stops being a macro language and becomes a language.

And of course that line is also blurry again, but since macro (and assembling) originate in simple substitutive behaviour or simple transformation, it is logical to define it a language if it starts to deal with abstractions allowing more involved transformations.

> In short, your claim is nonsense "by design" because basically there is no
> limit as to what degree an assembler is to collect and remember "type"
> information.
Can it handle arbitrary types? Will it really allow abstractions and check/transform them or does it just substitute a few numbers for your identifiers?

There is a hole there because at some level a compiler also substitutes numbers (the base principle is that it can

Post reply
 

Complete thread:

Back to the forum
Board view  Mix view
22755 Postings in 2121 Threads, 402 registered users (0 online)
DOS ain't dead | Admin contact
RSS Feed
powered by my little forum