Interviews
|
Interviews
| |
Thomas Richter is currently working on the mmu.library, which could become indispensable to programmers. He got the sourcecode of Enforcer from Manfred Sinz, which reprogrammes the software as MuForce and the yearned and never released software GuardianAngel as MuGuardianAngel. Because they get use of the MMU (mmu.library) they are superior to the old tools and in their efficiency. Also memory protection could be a theme.
| Thomas Richter: | If I may butt in: (-: I would not go so far and talk about memory protection. Under memory protection I understand, that program A must not work work with the data of program B and the other way around. Unfortunately the Amiga operating system is built that way, that all programs access the same memory, it is also spoken about "shared memory". That especially means, that one task can allocate memory and give it to a second task without problems and the memory can be released by a third task without the OS being informed about that. The efficiency of the AmigaOS is based on this mechanismn so a communication between processes (tasks) doesn't need to copy large amounts of data. This was important when introducing the AmigaOS on a 7 MHz clocked 68000. Memory protection was something nobody wanted (or could) to think about - it was in the far future. Unfortunately this concept lasted until today. |
| AMIGA aktuell international: | For the normal user this isn't an alternative anyway, because the system is extremely slowed down with this tool. But for Amiga software developers this means without any doubt a revolution. Any 68k-MMU is supported, from 68551 (68020) to 68060. |
| Thomas Richter: |
The idea of MuGuardianAngel isn't new, it is actually quite old and this tool isn't the first implementation of this
ieda as you mentioned before. The first version of such a tool was used by CBM internally, but I don't know, who wrote
the program (Mike Sinz?).
Unfortunately this hasn't worked correctly and the development was cancelled so noone - and this also includes me - hasn't seen this program. In Cyberguard is a similiar tool available with the "Guard"-option and in the Aminet there are tools, which can't be sorted to the tools, with are compatible with one another and partly they aren't even compatible with the own firmware, as Cyberguard - ppc.library and Cyberguard GUARD don't cooperate. I think, that the "common" user will not use such a tool normally. But it may be of a certain interest for software developers, at least I hope that. |
| AMIGA aktuell international: |
For users this library is of big importantce, too. Many applications/tools can be realized resp. made possible.
Why did you decide to work on the mmu.library? |
| Thomas Richter: |
The latest Amiga models got with the MMU (what that is I might explain later) a piece of hardware, that can be
used efficiently for memory management. Various programs use the MMU for their purposes like e.g. Enforcer for
tracing bugs in the software, further the OxxyPatcher, systems, that implements "virtual memory", various
emulators and more things. Unfortunately there is no documented interface for this hardware the all the Amiga operating
system, so tool A is not compatible with tool B and you have to have luck to hopefully getting a stable configuration.
The currently situation is approximately as absurd as the Amiga would be delivered without a graphics library and each program had to paint its windows with the hardware itself. So it is easy to understand, that this cannot work. What made me make this to change? Well, as a mathematician I might have an interest based on my job for tricky problems and their solution, maybe it can be explained that way. On one hand the problem is tricky enough to be interesting and on the other hand it is urgent enough to get done. For a hobby programmer this is motivation enough. If there were business interests no one would write anything for the Amiga, so unfortunate this may be. |
| AMIGA aktuell international: | What do you expect from it? |
| Thomas Richter: | A consistant interface for the MMU and a series of tools and applications, which cooperate without problems - and not at last I have something to think about and learn quite a lot about the hardware. In the end I get tools, that help me quite a lot with my own development work. |
| AMIGA aktuell international: | Since when do you develop this library? |
| Thomas Richter: | I carry this idea of the mmu.library for more than a year with me around. The trigger to really write this library was a discussion in the news group comp.sys.amiga.programmer, especially with Karl Uwe Lockhoff and many others. The design of the library was tricky enough so I began to implement it after thinking a lot in autumn/fall of last year and thanks to many helpful peoply to test and on this place I have to thank the community of nice testers, whose computers and hard disks I was allowed to use. It could have been much more difficult! |
| AMIGA aktuell international: | Will any 68k-MMU supported completely? Maybe there are some small limitations? Not all of our readers know the expression 'MMU'. Could you shortly explain it, please? |
| Thomas Richter: |
All the available MC 68ks are supported, beginning with the 68851 external MMU of the 68020 up to 68060 - the support
of the MMU is as complete as I could make it, beginning with the possibility to create multiple MMU tables and to give
each task its own address space - interesting for emulators e.g. about programming the page size of the MMU within the
technical possibilities up to the management of MMU exceptions like triggers through accesses on protected memory
areas. E.g. the "Enforcer&qout; doesn't contain any CPU/MMU specific code any more, it only uses a consistant
software layer of the library.
Because the unique MMUs differ something there are, of course, some limtations. The interface shall - has to - be the same, so I have to emulate certain features of a MMU, if this is possible, anyway. Without going into details, because then I would speak technicians language, the library doesn't e.g. the exotic features of the 68851-MMU, because they aren't present on any other member of the MC 68k-family approximately or were built in using trics. For the applications mentioned above these special features are of little interest. Another big limitation is the support of a PPC with the ppc.library, that means PowerUp. Because P5 didn't want to comment the ppc-library-internals there will not be a support of this in opposition to my previous plans. But WarpUp will be supported, just because it has been implemented with more deliberation so I don't have to special handling of the PPC it works already "that way". Because there is an emulation of the ppc.library for WarpUp under development this really doesn't mean a limitation. Eventually there will be also a support for a 68040 emulated by the PPC CPU, if there sould be a need for such a "special handling". The third problem are hard disk controllers with DMA, which don't make certain OS calls in opposition to the rules. For normal use of the library and the tools this is meaningless, but applications, which defragment the memory using the MMU, so they implement an efficient memory management will not work with these boards - something of this kind will not work, something of this kind doesn't exist in the moment, anyway. On one hand this concerns the boards of P5 again on the other hand the GVP adaptors. The last ones can be made "MMU compatible" with the Guru-ROM, not just because Ralph Babel was so nice to help and documented some internals for me. Known PIO adaptors as the well-known oktagon.device of Oliver Kastl don't have any problems with that. The problem doesn't exist due to the construction. Maybe I should answer the last question, I had to answer first, now: MMU means "memory management unit". The MMU is a logic, prior to the actual computing unit, today they usually integrated in the same chip - that catches any memory access, and eventually redirects and eventually forbids the CPU writing on memory accesses in the type as the CPU handles the built-in cache, controlles it and more. Accesses of the CPU and the memory are actually "censored" by the MMU, so that one memory address as it appears in a program hasn't to be the same with the physical memory address, which can be read from the bus of the computer. So the MMU can mirror the adresses of the Kickstart-ROM to RAM and replace slower ROM-accesses through faster RAM-accesses. The well-known "CPU FastROM" in the Startup-Sequence does exactly that. The "Enforcer" e.g. forbids the access of non-existent memory space, so the faulty software doesn't trigger an exception and make Enforcer "complaining" about that. |
| AMIGA aktuell international: | Which part can take this library/the MMU for the AmigaOS, because the implementation of e.g. memory protection isn't possible, anyway? |
| Thomas Richter: |
I think, that AmigaOS won't be of importance anymore, so the library will stay on a "hobby" level. I would be happy
about an interest of commercial software manufacturers, but due to the position of the Amiga on the market I think, this is
very unlikely.
On the other hand the library helps the developer due to the offering of the desired tools, on the other hand it helps due to offering of functions, that have been difficult or couldn't reached at all or with a loss of compatibility. Typical applications of the mmu.library - in addition to the previous mentioned developer tools - would be emulators or programs, which have to work in a "rough" environment and have to be protected from buggy software or even themselves. Debuggers or mailbox systems or servers are things, which occurred to me. But this protection has explicitely requested from the mmu.library, so it isn't presented from the OS and requires also an appropriate program design. A certain predecessor for editing programs is presently in an archive of the "MuLink" program, but the memory protection is only as compatiblity allows that and so it is incomplete. In the end the software developer has to use the library and do it himself. AmigaOS doesn't allow an additional *automatic* protection. |
| AMIGA aktuell international: | What exactly does the library mean for the developers and for the users (apart from bugfree software)? |
| Thomas Richter: |
For developers it means a quicker finding of bugs, of course. For the users it means a bundle of "Power-software&qout;,
which is guaranteed to cooperate and doesn't cut each others resources or stamps on the own feet.
First steps are made with the "MuTools", one of the "typical" MMU-applications from a ROM-remapper up to a debugging tool, similar to Enforcer, are included with this distribution. Basically this is the motivation for the library: To create a fine platform on which applications can make use of the MMU alltogether, like a graphics library. In the end this also means, that ideas of programs can be realised, that weren't possible before or only with a much larger amount of work and special versions for each processor and each configuration. This advantage of development is in the end an advantage for the "user", at least I hope that. |
| AMIGA aktuell international: | When will there be a first public release? |
| Thomas Richter: |
The releases are already public on my homepage
(http://www.math.tu-berlin.de/~thor/thor/index.html; Remark of the editor.)
and the more stable revisions regulary appear in the Aminet, but I'm usually reserved with that. I don't want to spread the
Amiet with "beta"-software because "beta = better than nothing" could be disappointing for the "common user".
It hasn't been tested that way as it should be.
Depending on size of the library in its current release - 0.35 - is already complete. If there will no new problems occur I hope, that a gamma version will be available in one month and the final version will be available in August or September. |
| AMIGA aktuell international: | What environment can be expected in combination with the mmu.library? Manybe a memory.library, new 680x0-libs?|
| Thomas Richter: |
I might write a "virtual memory" application, that is based on a library, this is the planned "memory.library".
The library will be based on the "mmu.library", of course. Based on the "memory.library" I plan a patch like
VMM, that offers "virtual memory" to the common applications, but with the "risks and problems" a patch of
this type brings with it.
I haven't decided yet, if there will be a 68040.library. Basically it would be necessary, because the current revisions make certain things "twice", that is a rudimentary MMU management, the mmu.library can do better and more comfortable. Certain program parts of the 68040.library, like e.g. the emulation of some FPU commands (floating point commands) can be found on the Motorola pages and are currently on my system. If I try again to implement them is still uncertain. Unfortunately I will be unable to write a 68060.library, because I just don't own a 060-based system. It was tricky enough to write the MMU support for a processor I don't know and I cannot test it not to mention to work to make the FPU emulation "blind". That's a bit too hard for me. |
| AMIGA aktuell international: | Will resp. could there be a PowerPC port? |
| Thomas Richter: |
Yes and no. I think I'm going to try to get the mmu.library run under a PPC emulation. It shouldn't be too much work,
because the 68040-emulation developped by Sam Jordan is quite complete - I think, the adjustment should be limited to
some details of the management of MMU-exceptions, if I have to adjust anything, anyway.
But it is most likely, that there will not be a mmu.library on the PPC-side, just because WarpOS itself offers functions for programming the MMU and the library would be of no use. But I cannot tell you much about the amount of MMU support of WarpOS, because I haven't dealt with how the PPC MMU works. The concept of it is a bit different to the MC 68k MMU, so the base of the design of the mmu.library cannot ported completely to the PPC. |
| AMIGA aktuell international: | Thank you for the interview. I wish you all the best! |
| Thomas Richter: | Thank you for your interest and have fun! |
The interview was made by Sofiane Ben Hassine.
