Re: [hatari-devel] ENABLE_SMALL_MEM problem

[Thomas Huth <th.huth@xxxxxxxxx>]

Am Sat, 23 Dec 2017 22:50:20 +0100
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:

> Le 23/12/2017 à 17:19, Eero Tamminen a écrit :
> > 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.
> >   
> 
> Hi
> 
> I see compilation issue was in fact due to a missing include and
> fixed by Thomas.

I only fixed the compilation step. It still segfaults when you try to
run the binary.

> Same as Eero, I don't have any opinion. On one hand, not using
> SMALL_MEM makes the code much simpler and I don't think any recent
> device don't have at least 16 MB.
> On the other hand, the code for SMALL_MEM is not that complicated
> either.

One advantage that you get with SMALL_MEM is that we might get a
cleaner memory handling. If something is accessing the area between ST
RAM and ROM/IO memory though it should not, we then notice it. Without
SMALL_MEM, these accesses go undiscovered.

> My "vote" would be to not change anything ;)  Default to not using 
> SMALL_MEM, but keep the SMALL_MEM code in case someone needs it.

Ok, let's keep it for now as it is.

 Thomas