aranym_configure_2

ARAnyM confguration (2)

In the previous talkative part of this series I described some first parameters of ARAnyM configure script. After a few weeks I wrote the second part of this series. In this part I'll describe the first part of the rest of them, the parameters, which can modify features of ARAnyM, mainly CPU and memory related.

Today, thanks years of development, ARAnyM can be compiled in many different configurations, in many different versions, from something nearly to Atari Falcon with Afterburner040, which was partial inspiration to something very modern, supporting e.g. PCI bus. In the first part I described the parameters which are interesting for developers. The rest of parameters could be inspiration also for advanced users, e.g. for speed improvements of their ARAnyM binary.

We can divide the options in many different classes in many different ways. I'll divide them in four classes:

• CPU and memory options
• HW emulation options
• NatFeat features
• Others

The options with the biggest impact are, of course, CPU and memory options. The first two are important for Memory Management Unit. This part of CPU is responsible for interaction between Memory (and also I/O memory space) and CPU. In ARAnyM it can operate in two main different modes - with "Full MMU" and without. In the first case, it emulates all features of M68040 and you can run Operating systems like GNU/Linux on ARAnyM. In the second case this part of CPU is reduced and is only a bridge between CPU and MMU, with no address translation and no memory protection. The name of configure script parameters is --enable-fullmmu and in default mode is "Full MMU" disabled, because it has important negative speed effect and cannot be mixed with Just-in-Time compiler (see later).

If you enable MMU, it could be interesting also the second option, --enable-fullatc. Address Translation Cache (ATC) is part of MMU and helps with memory translation (in real CPU has big speed improvement impact). In ARAnyM ATC has also some speed improvement impact, so this (new) feature is only for some experiments there and not important now. In default mode ATC is fully supported in "Full MMU" mode.

--enable-realstop option enables real STOP instruction. STOP is the special instruction which tells CPU that it could sleep till some interrupt won't comes. It has important impact on power consuming. Thanks Joy and STanda and Konrad and Frank you can take this advantage under EmuTOS and FreeMiNT today. It is nice mainly for somebody like me (actually I'm writing this text in train). In default mode it's enabled and could have only unnoticeable impact on speed and timer precision.

During long life of UAE CPU, there were written many different emulations of FPU. FPU is one part of CPU, responsible for floating-point computing. During long history of this unit on many different platforms there were developed many different implementations which are sometimes partially incompatible. Today one standard exists (developed by IEEE group) and is supported on all main platforms. But the old emulation cores are still supported because you can still find some errors in IEEE standard compatibility. In default mode IEEE core is preferred. The two others are original UAE core and x86 core (special version for x86 for older Pentium computers). You can select the core with --enable-fpe=FPE.

The next three options are very popular. They are used by many users on x86 platform (actually GNU/Linux and MS Windows are supported, OpenBSD version isn't maintained and NetBSD version was under development, but was discarded, because I couldn't find any good way for supporting it). Yes, these options are for Just-in-Time compiler which uses (short stupid description) compiled blocks of instructions with big speed improvement. They are

• --enable-jit-compiler
• --enable-jit-fpu
• --enable-jit-debug

The first option enables Just-in-Time compilation, the second also JITc for FPU instructions and the latest some debugging support. In default mode JITc is disabled and is forever only in development stage, because it's dependent on C++ compiler and CPU. With some new versions of C++ compiler and CPU it could need important modifications and mustn't work everywhere every time. All bug reports are welcomed also.

Small notice for PowerPC users. There were/are some people around UAE and BasiliskII who are developing JITc for PowerPC and also Xavier Joubert disclose informations about his games with it, but after announced migration of Apple to x86 platforms there isn't so big interest last weeks.

Before switching to Memory options, there are some other, minor CPU options still. The first is --enable-disdip. In older GCC (2.95.x) it was possible with small modifications to do direct jumps between functions with similar structure of stack. Thanks it, it was possible to develop version of standard CPU core with speed improvement on x86 platform around 15%. This feature was nearly fully portable (it works e.g. on Sparc Solaris) but after important changes in later version of GCC, it isn't possible to use it again. Hopefully it was reborn in future.

--enable-spcflags-excl option enables exclusive spcflags handling and is important for threads synchronisations in CPU core. In some cases it isn't important but in prevailing cases this option is automatically enabled by other options.

--enable-cxx-exceptions option belong to the youngest options and enables using of C++ exceptions instead of setjmp/longjmp. On some CPU with big bunch of registers it can be quicker than original set/long jumps.

--enable-epslimiter option is only for development purposes and enables Exception per second limiter. With this option you can set amount of exception per one second (in aranym config file).

The next four options are oriented on interaction between CPU and Memory. They are different to MMU options, because they aren't about some HW, but about implementation. The first two have important speed impact, the second two minimal.

• --enable-addressing=AM
• --enable-addr-check=AM
• --enable-fixedfastram=X
• --enable-fixedvideoram

There is 3 supported addressing modes actually:

• real
• direct
• fixed

All three modes are based on memory map (mmap) function and map /dev/zero device to map on needed positions. The difference is in the starting address of their mapping. The "real" mode use possibility to map device from the first address. Thanks it ARAnyM doesn't need to do memory shifts during every address adjustment. It's the quickest mode in ARAnyM but has a few limits. The main limit is that it isn't support on all platforms. And the second is that size of memory is limited in this case, because e.g. on GNU/Linux, the text space (mapping of aranym binary to memory) starts from address 0x12D39DA80 (128 MB). It depends on your platform.

If your platform isn't supported (e.g. even Linux based Fedora Core distribution), you should use the "direct" mode, which doesn't map from any fixed address, the starting address is selected by system memory management and ARAnyM must do shifts every address adjustment.

The "fixed" mode is a special addressing mode for JITc, it maps memory from address which is optimal for JITc.

--enable-addr-check options has really big impact, but typically is autoselected optimally for your platform and configuration. With this option you select how ARAnyM should check if the used address is accessible. There are many possibilities:

• no - there isn't any check. It's stupid, malfunctional, only for tests
• full - every address adjustment there are some tests which test the address for accessibility (e.g. some parts of memory aren't writable).
• page - this version remembers last accepted address and if the new address is in the same page (size is 1 MB in mode without "full" MMU support), the address is accepted.
• hwsp and pagehwsp and sseg - are based on host operating system segmentation fault handler.

Better description you can find in Hguide of ARAnyM, in chapter "Checking memory boundary". For the standard CPU the "page" mode is optimal in nearly all situations. With JITc the "sseg" mode is automatically activated, there isn't any other possibility.

With Fixed FastRAM option you can set size of FastRAM memory to some constant and it could be used by compiler to some unimportant optimisation. And with Fixed VideoRAM option you set the starting address of VideoRAM to 0xf0000000 and it's needed for "full" MMU support. In other cases the starting address is variable.

The latest core systems related function is --enable-purec, which enables corrupted stack format, because PureC debugger doesn't support M68040 stack format directly. It's only for PureC developers, don't use it if you don't really need it.

Ups, so long, again. So, the rest next time.