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