interpreter questions regarding memory model...Squeak for BeOS
Serg Koren
skoren at pop5.ibm.net
Mon Jan 26 05:27:22 UTC 1998
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 at 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 at interval.com (w) +1 (650) 856-7230 (w)
> tim at sumeru.stanford.edu (h) <http://sumeru.stanford.edu/tim>
>
More information about the Squeak-dev
mailing list
|