Re: [hatari-devel] Hatari on constrained devices

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


Hi Thomas,

Does debugger work properly with SMALL_MEM config?

(e.g. doing "profile on" and getting backtrace for a program with debug symbols when dropping to debugger for second time?)


	- Eero

On 7.1.2022 23.05, Thomas Huth wrote:
Am Thu, 6 Jan 2022 13:25:46 +0200
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
I noticed that you removed WinCE support.

I removed the Hatari v1.x config examples for other constrained
devices, as they're not supporting SDL2 either.

Good idea, thanks!

Should the SMALL_MEM option be removed too?

I think we could remove it nowadays, yes - but actually I rather tend
to make SMALL_MEM=1 the default nowadays. Rationale:

- The huge STRam[16MiB] array is kind of ugly

- If we ever have a bug in one of the IO memory or ROM access
   functions, it might be possible for a malicious Atari program to
   access other variables in the BSS of Hatari (since they are in
   well-known locations relatively to STRam[]) - if we malloc the memory
   instead, the chances are way smaller that something ugly could happen
   here beside crashing Hatari.

- I think the speed optimization that we get via the huge static
   STRam[] array is completely neglectable on modern CPUs. Actually, I
   just also did a completely unrepresentative benchmark by running
   two Hatari instances in parallel and comparing their CPU usage with
   "top", and the build with --enable-small-mem was even 0.3 % up to
   1.0% better than the one without --enable-small-mem! Might be just
   noise, of course, but at least there is no big difference between the
   two modes.

So unless someone has some good objections, I think I'm simply going to
switch the code to use the SMALL_MEM behavior by default.

  Thomas





Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/