Hi Tim, Thanks for the thoughts. I agree that things that refer to hardware (such as memory and file access) should be exported to the platform specific sections of the code. Once I get back from my business trip I'll look into restructuring the inner interpreter into a more OO format.
Now if only someone rewrote the ST->c code to be ST-C++ ;-) Cheers, S
On Sunday, January 25, 1998 11:54 PM, Tim Rowledge [SMTP:rowledge@interval.com] wrote:
On Sat 24 Jan, Ian Piumarta wrote:
My suggestion would be to avoid malloc entirely and to allocate an area
of memory
by some other means, in a way that leaves you certain that it can only
ever be in
the lower half of the address space.
I agree with this idea entirely. In order to make use of an extended
memory controlling API on the Acorn, I have to change the VM code to call platAllocateMemory() instead of relying on malloc(). As it happens, it speeds up GUI responsive
ness by about 5 times, but that's just a quirk of the Acorn OS.
I did suggest such a change to JohnM some time ago, but it looks like he
never got time to include it. My rationale was that it couldn't hurt anybody and would help me, but now it looks like it might help someone else as well.
Actually, I'd suggest it might be useful to indirect ALL calls to
'outside' apis, so that the platform specific code can cleanly intercept any that might not be suitable; there aren't many so it wouldn't be too onerous. Let's see, malloc,
fread, frite, fseek, fopen, fclose, math stuff.... that's about it. The
easy way would be to have the SQ code refer to some munged name and to use macro definitions to make use of the 'normal' calls where acceptable.
Thus we could easily intercept all the file handling but leave macros for
exp, floor, sin etc.
tim
-- Useful random insult:- Supports nativist theories that man is formed from
clay.
Tim Rowledge: rowledge@interval.com (w) +1 (650) 856-7230 (w) tim@sumeru.stanford.edu (h) http://sumeru.stanford.edu/tim
squeak-dev@lists.squeakfoundation.org