Serg,
memStart would be negative.
I've often worried about this. When I did the initial port of Squeak to SunOS I suspected one problem of being caused by malloc returning a "negative" address (it turned out to be something entirely different). I had similar worries about the DEC Alpha port, where Squeak "only just" manages to scrape by as a 32-bit application living ("squatting"? ;) in a 64-bit universe -- but using the relevant flags to the linker seems to ensure the correct behaviour.
Andreas suggests ensuring that the compiler treats ints as unsigned. If you can do this then it'll work (gcc, for example, has -funsigned-char but I don't think it has -funsigned-int). However, there are literally hundreds of places in the interpreter where addresses are implicitly assumed to be non-negative 32-bit signed values, and I'd be terrified of trying to convince myself that the interpreter were 100% correct with any smple "workaround". Even #defining int to be unsigned int would leave me scared, since there's no way to know what secondary effects this might have on stuff imported from header files (even if the #define was always done after the last header file were included -- since #defines are felt inside other #defines at expansion time, not definition time).
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. One possibility would be to mmap() the object memory from /dev/zero, at an address that you know to be safe -- you would be able to treat the memory so allocated pretty much like that allocated by malloc(). Another possibility might be to investigate if the BeOS linker has flags to control where the uninitialised data segment is mapped for an application: if you can set this manually, then you should be able to choose a suitable "safe" address.
If you run into real problems with this then let me know. I have BeOS installed on my Mac, so I could try to come up with a suitable workaround for you.
Sorry that I can't offer anything more positive and/or helpful and/or concrete... :(
Regards,
Ian
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
Tim Rowledge wrote:
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.
I second this.
When dealing with code for the Newton, which doesn't support files, this is a source of complexity. For the most part, it isn't that bad. But there is one place in the VM when it starts up where the shell creates a file handle and passes it to the VM (for reading the image) which created the worst difficulty. That is one place that Squeak does not use its own file primitives and the workaround is ugly.
It would help if there was a test program written in C that exercised the Squeak shell code. The test program woudl be much smaller than Squeak itself - like one hundred lines of code or so. That way a port could focus on getting a shell to work first.
That test case could be as simple as: Draw a diagonal line, respond to a mouse down or key by drawing another line, play a sound, and maybe read a file. These could be individual tests or run together based on compiler flags. One could progress in some arbitrary order - like first get the bitmap to work, then get keyboard, then the mouse, then files, then TCPIP, then sounds. There could be feedback provided at each stage by the test program.
On a related issue, there is much value in having a machine independent GUI shell that collects keystrokes, tracks the mouse, interacts with file like streams, displays bitmaps, does TCP/IP, and plays and records sounds. With a little restructuring, the Squeak shell could turn into a beautiful machine independent framework on top of which *anything* could be placed. This might entail a slight performance hit depending on how nternal Squeak data structures like strings were passed to the shell.
For example, if a group wanted to make a portable version of Python with TK widgets, they could just put it on top of the Squeak shell platform.
This would potentially bring a lot more people into the machine independent Squeak shell API fold. Even though they wouldn't have much to say about Squeak, they might have an interest in porting the Squeak shell to new platforms for their own reasons, and then Squeak could follow. It might also multiply the number of people interested in sharing the work of maintaining and debugging existing Squeak shell ports.
Maybe if the Squeak low level API had a name it would be treated more like a thing on its own. Anyone with a catchy name for the Squeak shell and related API? Conch? Squeak API? Squeak Happy? The Nest? Squeal? Low Squeak? Rumble?
-Paul Fernhout Kurtz-Fernhout Software =========================================================== Developers of custom software and educational simulations Download our Garden Simulator for Windows & source from: http://www.gardenwithinsight.com
Paul Fernhout writes:
Maybe if the Squeak low level API had a name it would be treated more like a thing on its own. Anyone with a catchy name for the Squeak shell and related API?
Whiskers. For finding your way in the dark.
-- rec --
squeak-dev@lists.squeakfoundation.org