Path: chuka.playstation.co.uk!news
From: Christoph Luerig <cpluerig@immd9.informatik.uni-erlangen.de>
Newsgroups: scee.yaroze.programming.codewarrior
Subject: SIOCONS compatibility solved
Date: Mon, 09 Nov 1998 11:10:49 +0100
Organization: PlayStation Net Yaroze (SCEE)
Lines: 65
Message-ID: <3646BFA9.D7B25BD6@immd9.informatik.uni-erlangen.de>
NNTP-Posting-Host: faui90.informatik.uni-erlangen.de
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 4.04C-SGI [en] (X11; I; IRIX 6.3 IP32)

Hello!

Yesterday I came more or less accidentally to a solution of a problem,
that may also interest some other people.
The problem was, that I have written a program that makes use of the
heap area and the MWDebugIO functionality,
But some people needed the program in a siocons compatible format, that
loads all the data in advance at fixed addresses.

I needed the heap, as I have quite a lot of transient data during the
intialization stage. One possible solution would be to split the memory
in two halfes, one is reserved for the heap and the other one for the
initially preloaded data. This would not work neither as the amount of
preloaded data
is quite large and would not leave anough space for the heap. The second
solution would be to reinitialize the heap to
a greater extend, if all preloaded data is moved over to the video
memory/ the sound buffer. The problem however is, that I allocate
some data structures in the heap before everything is moved over to the
videomemory. I would probably get lost of this data, if I reinitialize
the
heap inbetween.

The solution to this problem is very dirty. The idea to exploit here, is
that the operating system does not assign memory areas
to the program, as you have in oridinary operating systems. This means,
if you allocate memory at the beginning of the program, the playstation
will allocate the memory again at the same position, if you run the
program again. I now calculated how much memory I would need to take all
preloadable files. For administration purposes I divided this complex in
three chunks. Then I allocated the memory and looked, where these chunks
are positioned.
I took these addresses as the destination address to preload my data.
This way the memory area is protected as long as I want. This is really
bad style and I know this. Every time the program is modified (even when
switching from debug to optimized) the addresses have to be
recalculated. I talked about this
to one of our low level programming freaks at our lab today and he said,
that I am lucky, that this works anyhow. Usually malloc implementations
modify
some of the memory out of the mallocated area for pointering the
different memory chunks. As I allocate three consecutive memory chunks,
the memory
in the second and third block could be altered. Well experiments have
shown that they are not altered, or at least there is enough space
between the blocks
that one does not get interference problems.

This brings me to a quite interesting extension idea, that would solve
this whole problem. The idea would be to implement a malloc routine,
that gets besides thed required memory the position where this memory
should start as an extra parameter. As a result this method would return
either success or not. I know that this is absolutely ridiculous, but
the fact, that the batch file uses absolute addresses for their data to
preload and the fact that some people
insist on using this method, makes it necesarry to think about absolute
addressing problems in the program.  This is very pitty to my mind, as I
think, that
the Codewarrior programming environment shields the programmer quite
effectively from these uninteresting low level details.

Christoph Luerig