Hi,
On 12/23/2017 10:16 AM, Thomas Huth wrote:
I recently tried to compile Hatari with ENABLE_SMALL_MEM again, but it
is currently broken: Main_Init() calls STMemory_Init() which again
calls STMemory_Reset() and that accesses IoMem[], causing a
segmentation fault. IoMem[] is not available in ENABLE_SMALL_MODE until
memory_init() has been called during TOS_LoadImage(), which happens
later in Main_Init() (when it calls Reset_Cold()).
So we either have got to change the order here a little bit, or maybe
remove the call to STMemory_Reset() from STMemory_Init() ? The latter
should likely be OK since STMemory_Reset() is called again from
Reset_ST()? Nicolas, do you have an idea what's the right fix here?
Anyway, since ENABLE_SMALL_MEM tends to bitrot every year, we should
maybe also consider to get rid of this special mode (after the next
release?). It has originally been included to be able to run Hatari on
machines that have very limited RAM or are unable to provide a BSS
array of 16 MiB due to any means (e.g. old Windows CE smartphones). I'm
not aware of any such system left nowadays, even the smallest embedded
systems have hundres of MiBs of RAM nowadays.
So we could simply rip of the related code. Another idea: Rip out the
non-SMALL_MEM code and make the SMALL_MEM code the default mode
instead, so that we always malloc the STRam instead of using a huge
16 MiB array for everything, ST RAM, ROM and IO memory. Using
malloc() sounds like a cleaner approach, and recent CPUs should really
be good enough so that you should not see a performance difference
between the two modes anymore today, I guess... Any opinions?
I don't really have an opinion either way. I doubt current Hatari
would really run on devices with too little memory, as ones with
that little memory would probably also be too slow to run current
Hatari at good speed.