1. Before you go on.....
Hy,
Can someone explain what a "Dos Extender" and Causeway is ?
And what a compiler is. (I tought that BIND.EX was one)
Bye,
PQ
QC
Get Your Private, Free Email at http://www.hotmail.com
2. Re: Before you go on.....
- Posted by JJProg at CYBERBURY.NET
Mar 14, 1999
EU>Hy,
EU>Can someone explain what a "Dos Extender" and Causeway is ?
EU>And what a compiler is. (I tought that BIND.EX was one)
EU>Bye,
EU>PQ
EU>QC
EU>Get Your Private, Free Email at http://www.hotmail.com
I don't have much experience with DOS Extenders, but I believe they
basically provide extra functions for programs to use. A compiler
converts source code into machine code. bind.ex is not a compiler
because it only attaches the source code to ex.exe; it doesn't convert
it to machine code.
Jeffrey Fielding
JJProg at cyberbury.net
http://members.tripod.com/~JJProg/
3. Re: Before you go on.....
- Posted by Robert Pilkington <pilking at BELLATLANTIC.NET>
Mar 14, 1999
-
Last edited Mar 15, 1999
>Can someone explain what a "Dos Extender" and Causeway is ?
>And what a compiler is. (I tought that BIND.EX was one)
Normally, DOS uses a mode called Real Mode that only lets programs access
the first 640 kilobytes of RAM. Upper memory, which is above 640k and below
one meg, is used by programs like MOUSE.COM and MSCDEX.EXE that run in the
background. (Heh, TSRs are kinda like multitasking in DOS...)
The rest of the memory can be accessed in two ways: Expanded memory and
extended memory.
Expanded memory requires a memory manager like EMM386, and is slow because
you must page in blocks of 4k, I think. (Or is it 64k? Oh well, we don't
have to worry about it.. Read on. 
Extended memory is accessed by a DOS Extender. Causeway is a common DOS
Extender used by Euphoria and one of my favorite games. Another common
extender is DOS4GW. (Look for DOS4GW.EXE on your harddrive... you should see
it for many DOS games.)
DOS Extenders are cool because they make it easier to program... (Far and
Near pointers aren't needed in C, for example.) You also don't have to worry
about that 640k limitation in all but a few cases.
A compiler just converts code to computer readable form. Euphoria is an
interpreter and 'compiles' the code as it's being run. Bind and Bindw shroud
the source and append them to a copy of EX.EXE or EXW.EXE.
Ok, long, but I think it answered your question in more detail than you
wanted.
4. Re: Before you go on.....
> I don't have much experience with DOS Extenders, but I believe they
> basically provide extra functions for programs to use. A compiler
> converts source code into machine code. bind.ex is not a compiler
> because it only attaches the source code to ex.exe; it doesn't convert
> it to machine code.
There is no real definition of a compiler vs interpreted.
Take the JIT-Technology... it compiles Java-code and then executes it. It thus
takes source code and executes it.
Its an interpreter. But what if I would bin the interpreter and the java-source
code together ?
The code is not compiled yet, but it is an executable, and will run as fast as a
compiled program.
My point is just that, even if you would make a compiler out of interpreter like
Euphoria, the eventual program would not be so
much different than the one you now have. There would only be a few 'jumps'
extra here and there.
Why ? Because many parts of the program use the same routine, we thus call it.
Machine code to call such routines, or a
stack-based interpreter that call those routines: little difference. There would
only some extra jump routines.
However, in theory, it could *optimize* your code at the cost of compile-time.
But I don't know any strong optimization that takes too long to be happening in
the interpreter.
Ralf
5. Re: Before you go on.....
At 07:46 3/15/99 +0100, Ralf Nieuwenhuijsen wrote:
>> I don't have much experience with DOS Extenders, but I believe they
>> basically provide extra functions for programs to use. A compiler
>> converts source code into machine code. bind.ex is not a compiler
>> because it only attaches the source code to ex.exe; it doesn't convert
>> it to machine code.
>
>There is no real definition of a compiler vs interpreted.
I have to disagree somewhat here. While it's true that some
modern interpreted langauges have blurred the distinction between
compilers and interpreters, the classical distinction is that
compilers compile source code to machine code, while interpreters
compile source code to some intermediate representation which then
must be processed by an interpreter at run time. Once started,
compiled code does not need any assistance at run time, and thus
usually executes faster than interpreted code (depending on the
design of the language and the quality of the compiler, etc.).
Another way of looking at it is that compiled code is "interpreted"
by the CPU itself (very fast) instead of by some other piece of
software (relatively slow). Euphoria, BTW, is amoung the fastest
of interpreters and probably would execute only a little faster
if compiled.
--
Don Groves
>Take the JIT-Technology... it compiles Java-code and then executes it. It
>thus takes source code and executes it.
>Its an interpreter. But what if I would bin the interpreter and the
>java-source code together ?
>The code is not compiled yet, but it is an executable, and will run as fast
>as a compiled program.
>
>My point is just that, even if you would make a compiler out of interpreter
>like Euphoria, the eventual program would not be so
>much different than the one you now have. There would only be a few 'jumps'
>extra here and there.
>
>Why ? Because many parts of the program use the same routine, we thus call
>it. Machine code to call such routines, or a
>stack-based interpreter that call those routines: little difference. There
>would only some extra jump routines.
>
>However, in theory, it could *optimize* your code at the cost of compile-time.
>But I don't know any strong optimization that takes too long to be happening
>in the interpreter.
>
>Ralf
