1. Memory Allocation in EXW.EXE
Ok, I have yet ANOTHER question in my quest to perfect FILEMAN.E
In my haste to rewrite FILEMAN using DOSWRAP, I did not realize that
allocate_low() is a function of EX.EXE, and does not work in EXW.EXE.
Of course, there's always allocate(), but DOS interrupts require that
blocks be allocated in conventional memory. My question is, does anyone
have any ASM routines which will work for me?
I know that int48h and 49h control allocation/deallocation of memory in
DOS, but my ASM skills are nil, and I haven't been able to get anything to
work. If somebody could write a quick malloc/free routine for EXW, or
send me some working ASM source, I'd REALLY appreciate it.
Thanks in advance,
Brian Jackson
bjackson at printinginc.com
2. Re: Memory Allocation in EXW.EXE
Brian Jackson writes:
> In my haste to rewrite FILEMAN using DOSWRAP, I did not realize
> that allocate_low() is a function of EX.EXE, and does not
> work in EXW.EXE. Of course, there's always allocate(),
> but DOS interrupts require that blocks be allocated in
> conventional memory. My question is, does anyone
> have any ASM routines which will work for me?
In WIN32 (exw.exe) you can't do DOS interrupts, therefore
allocate_low() is not needed.
I'm not sure why you are using DOSWRAP.
Euphoria has a seek() function for random seeks within a file.
seek() works in DOS32 and WIN32.
In the past, some people have spread unsubstantiated rumours
that file I/O in Euphoria is slow, but no one has ever come forward
with a benchmark to prove it. In the Kernighan benchmarks
Euphoria did quite well on the file I/O benchmarks compared
to several other languages, including C.
Regards,
Rob Craig
Rapid Deployment Software
http://members.aol.com/FilesEu/
3. Re: Memory Allocation in EXW.EXE
>In the past, some people have spread unsubstantiated rumours
>that file I/O in Euphoria is slow, but no one has ever come forward
>with a benchmark to prove it. In the Kernighan benchmarks
>Euphoria did quite well on the file I/O benchmarks compared
>to several other languages, including C.
In that case, my apologies. I was under the impression that the built-in
I/O routines were much slower. I will try reverting to the built-ins, and
see what happens. Back to the drawing board :)
Brian Jackson
bjackson at printinginc.com
4. Re: Memory Allocation in EXW.EXE
>I'm not sure why you are using DOSWRAP.
>Euphoria has a seek() function for random seeks within a file.
>seek() works in DOS32 and WIN32.
>In the past, some people have spread unsubstantiated rumours
>that file I/O in Euphoria is slow, but no one has ever come forward
>with a benchmark to prove it. In the Kernighan benchmarks
>Euphoria did quite well on the file I/O benchmarks compared
>to several other languages, including C.
Actually, its not file i/o that is slow, its the 'interface' that causes it to
become slow.
An example:
Reading a whole file upto the EOF
constant
NONE = -1 -- one of three booleans
global function read_textfile (sequence fname)
sequence s
integer char, fh
fh = open (fname, "r")
if fh = NONE then
return ""
end if
s = ""
char = getc (fh)
while char != NONE do
s = append(s, char)
end while
return s
end function
This function is slow.. why ? Because we are dynamically building a sequence.
The file IO is streaming only. Thats where the problem lies.
In any type of IO program the problem relies in the fact that (with the
exception of seek) the files are streams.
And therefor, half of the time, we need performance eating and 'rather' complex
algorithms to use file IO the way we want it.
Robert, I agree with you on 'minimal' language, but is it clean to program a
multiplier as a loop containing single additions ?
Would it be reasonably fast and is it easy to maintain ?
Im still in favor of being able to 'load' a file as a variable.. where accesses
to that variable are simply 'cached'. (maybe I
should have enqouted 'simply' here rather than 'cached' ... 
It would thus work as if it was a cached variable under VM.
Changes would be stored immidiately. Off course 'immidiate' editing isnt the
best choice for most solution, I dont think the
immidiate editing tools should be that extensive. For example, initially the
structure would be one-dimensional, but you could
change that for run-time purposes if you want to. It would get into the
'brilliant' leauge' when we would be able to change the
file 'mode' .. from and to: text, binairy, euphoria. Where 'Euphoria'
represents a special mode in which structure is saved
as well in an efficient way. Automatic compression would be great, but simple
and smart efficiency (store the *real* amount of
bytes needed to represent the value in the structure) can already do alot.
Ralf
