Category Archives: Developer Info

AmigaOS 4.1 Final Edition SDK now available

blog_devThe AmigaOS 4.1 Final Edition SDK is now available for download from Hyperion’s web site. The official press release can be found at http://www.hyperion-entertainment.biz/

This is a significant update to the SDK which will require a lot of developer support to use properly. New articles have already began to appear on the AmigaOS Development Wiki like Intuition’s new Menu Class article.

We are also planning tutorials and a workshop at the Amiga DevCon 2015 which is before the AmiWest 2015 show in Sacramento, California, USA starting October 15th.

Steven Solie
AmigaOS Development Team Lead

AmigaOS Documentation Wiki and Amiga DevCon 2015

blog_devThe AmigaOS Documentation Wiki (http://wiki.amigaos.net) is moving to a brand new server. The new server is quicker and also enables important upgrades to the underlying software driving the wiki.

It always takes a few days for the DNS propagation to complete so the URL may not work in your region yet. In the mean time, you can use http://78.47.81.180/wiki to access the wiki. You can monitor on the DNS propagation progress using services like DNS Checker.

Amiga DevCon 2015

Moving and upgrading the AmigaOS Documentation Wiki is just one small step towards Amiga DevCon 2015 which is taking place in Sacramento, California, USA on October 15 and 16 before the AmiWest 2015 show. With the release of AmigaOS 4.1 Final Edition there is a need for an updated AmigaOS SDK. The SDK includes some important AmigaOS API improvements and these will be covered at the DevCon and more.

Don’t worry if you can’t make the Amiga DevCon in person. All the presentation materials will be available on the AmigaOS Documentation Wiki in the Tutorials section.

Steven Solie
AmigaOS Development Team Lead

Multicore and Amiga: Present and Future

blog_devSymmetric Multi-Processing (SMP) is on the wishlist of AmigaOS users for quite some time now, and while progress has been made, we’re still not there yet.

To explain the progress, let us first look at the concept, and then point to where we are in the whole.

Concept: Threads, Cores and Processors

When looking at SMP support, we need to take actual processor technology into account. Older implementations used actual physical processors for SMP, that is, one processor could execute one instruction stream, and to achieve parallel execution, you would be able to plug in more processors. Usually and not surprisingly, this is rather limited in the amount of processors that can communicate with each other (although there were massively parallel machines that used a complex interconnection network for communication).

Later on, chip manufacturers added additional so called “cores” to one physical processor.

A very recent development is the ability of such individual “cores” to execute more than one instruction stream in parallel. We call those instruction streams threads. This technology is used in such CPUs as the Intel Core i7 (where it is named hyper-threading), or the Freescale e6500 core, which is used on the T-series CPUs from Freescale (up to the T4240, which has 12 physical cores with two threads each).

How to schedule tasks in SMP configurations

When looking at how to schedule Exec tasks and processes on a SMP system, we need to look at how much overhead is involved with scheduling. Currently, in single-CPU environments, Exec periodically interrupts execution and evaluates whether it should pick another task to run. Doing that with high frequency, say, 20 or 30 times per second creates the illusion of multiple tasks running in parallel.

The evaluation whether a new task should run or not is done based on the tasks priority, or depending on whether the task has something important to do. Of course, this takes time as well, and if the time taken for this evaluation becomes too long, the machine will take more time evaluating what to run than running what it is supposed to.

This gets worse if more execution units are in the system: If the evaluation would also need to ask other CPU cores whether they want to run something, the time for this processing would rise tremendously, to a point where adding more CPUs to the system would actually slow it down.

Therefore, the scheduling of Exec tasks and processes will remain something a single CPU will do for itself, even in multi-core. This will ensure a reasonable time is spent on this task.

So, how do multiple cores, threads and/or CPU’s come into play ?

We can easily monitor how loaded a core is by checking how many of the tasks we have ready actually got time to run. This is called the “load” of the CPU. If it spends a lot of time waiting for tasks to become available, the load is low. If a lot of tasks are waiting for their turn to run, the load is high.

In a multi-core system, some cores will have high load, and some low. To balance this, the system will look at the load of the individual core and determine whether there is a need to balance out the load among the CPUs or not. This balancing is triggered by the individual schedulers when they notice that their current workload is too big for them to handle. In this case, the overloaded core will migrate some of its tasks to other cores until it can again handle its workload.

Scheduling domains

In the previous section, we talked about balancing. Let’s take a closer look at this. A task running on one core is usually using the core’s resources. An important resource is caches: Level 1 caches (L1) contain data from memory very close to the CPU’s instruction units, so accessing this data is instantaneous. A level 2 cache (L2) is something that is below the Level 1 cache, is usually bigger, and access to it is slightly slower than accessing the level 1 cache. Some systems even have higher level caches below the L2 cache.

In a typical multi-core system, the L1 is exclusive to one core, while the L2 is shared among many cores. However, as in the scheduling example, more cores accessing one L2 means more overhead in communication with the L2 because some core might be waiting for another core to finish accessing the L2. The more cores access the same L2, the more likely such a stall is. Therefore, some processors with a high number of cores have multiple L2 with groups of cores sharing that L2 while another group shares another L2. We call those groups “clusters”. As an example, the T4240 has 12 cores, grouped in three clusters of four cores each, with each cluster sharing their own L2 and each core having a separate L1. In addition, there are cores that can run multiple threads at once. These threads even share the L1.

What we see here is a hierarchy of execution units. Clearly, moving a task from one thread to another thread on the same core is a rather cheap operation, the migrated task will not suffer from misses in the L1 since it still uses the same one. On the other hand, migrating from one core to another one means that the new core will not have access to the L1 of the previous core, and thus, migrating to this core will come at a slight initial performance cost. Similarly, migrating across to a new cluster will mean the task will lose the benefit of both the L1 and the L2, resulting in an even larger initial performance cost.

As you can see, moving a task to another execution unit will have different degrees of performance penalties. Note, these are only “initial performance” penalties, since the caches will gather the necessary data over time so that after some time, the caches will be fully available again to the task.

This hierarchy is in essence the hierarchy of “scheduling domains”. Scheduling domains define a cost associated with moving a task from one core to another. When balancing the load, the system will strive to minimize the cost of movement to ensure minimal performance loss. Migrating inside the current scheduling domain will always be cheaper than migrating to some core outside of the current scheduling domain, however, if all cores in the task’s scheduling domain are overloaded, the higher cost will need to be paid.

Pitfalls: The dreaded Forbid

Adding this functionality to AmigaOS is not without problems, naturally. There is one central part of the OS that has been around since its very beginning, and has been widely misused and misunderstood: The Exec function Forbid (and its counterpart, Permit). The problem with these functions is both semantic and practical. It has been documented as disabling task switching, and as enforcing the system to become single threaded.

If you look at this, these are one and the same on a single core system, but something completely different in SMP. Forbidding task switching in an SMP system will have a number of threads running in parallel. No CPU core will switch tasks, since it is forbidden to do so, but the system is not running single threaded at all.

This misunderstanding has lead to a lot of misuse. Forbid has been used to basically protect critical data structures from tampering with by other threads. Of course, this will work in a single core system: Prohibit task switching, and you can be sure that no one else will get to access that data. In a SMP situation, however, this does not stop anyone from accessing it.

So what’s the solution to this ? Keeping in mind that Forbid is mostly used to protect critical sections of code and data, the SMP enabled kernel will treat it just like that: Any core issuing a Forbid call will, simply put, write its number into a field somewhere in the system. It will do this “atomically”, meaning that the memory is only modified if no one else is competing for it. If it succeeds, it can proceed into the critical section. On the other hand, if there is already some other core in the critical section, or the write did not succeed, it will repeat this process until it succeeds, basically stalling the competing core until it is successful. This ensures that only one core at any time can enter into a Forbid state, and any subsequent core that wants to forbid will have to wait until its turn.

Of course, this is a simplified description of the process. Some other things are necessary to ensure fairness and equal distribution of access, to prevent one core from hogging this “lock” for too long, and so on, but the basic process works like this.

Where are we now ?

The development of SMP support has been separated into several distinctive steps. The first step was to rewrite the scheduler in C for easier accessibility. In the very end, this step might be reversed again, rewriting the then SMP capable scheduler back into assembly language. The second, more fundamental step was to decouple the scheduler from its current data structures. As you might know, ExecBase contains a lot of list for task that are ready, or waiting for a signal.

This has now been achieved. The current development build uses a scheduler that no longer uses the original AmigaOS data structures, but a structure that is replicated for each core.

The next step is to have each core in the development system (currently, the X1000) to run the scheduler. Test code will then start tasks on the different cores and see how they behave. We have already experimented with this and the results look promising. The tests basically showed that the lockout mechanism for Forbid works as planned.

As a final step, the balancing will be introduced, which then finalizes the first implementation of SMP support in AmigaOS.

Future plans

There are several possibilities to chose from once the first implementation is done. First of all, the scheduling algorithm is still the same as the one used by current Exec, a priority modified Round-Robin. Naturally, this is an algorithm that can be improved upon. There are several other implementations that come to mind, like the O(1) scheduler, multilevel feedback queues or even the Brain Fuck Scheduler.

Also, the balancing algorithms are candidates for improvement. The system might record scheduling data and compute typical user profiles that can be pre-selected, like, for example, the ability to determine when to balance, and how aggressively balancing is carried out.

AmiWest 2014 Programming Jam

blog_devWe are extremely pleased to be able to host the 3rd incarnation of the AmiWest Programming Seminar. This is a unique event in the AmiVerse, to bring together Amiga developers, programmers and users to learn from each other and create apps.

In previous years we have taken a more formal approach with seminars and fixed topics. Given the wide range of programming experience on the part of participants, we will try a more free-form approach this year.

To read more and get more information, check out this link:

http://www.amiwest.net/aosps/

Here’s the sign up form:

http://www.amiwest.net/survey/index.php/816728/lang-en

Paul Sadlik
AmiWest Programming Jam Organizer

Breaking the Memory Barrier

Overview

AmigaOS is a 32 bit OS. There is little we can change about it. The size of an address pointer is intrinsically entangled into the API, and getting rid of this legacy is, for the most part, a matter of replacing all of the API with a new one. Every time a programmer writes something like “sizeof(struct Message)”, the 32 bit nature is fused into his code.

This has some repercussions that cannot be easily ignored. It means that our address space is inherently limited to 32 bits (meaning 4 gigabytes). In reality this space is even smaller than that. PCI space, the kernel, memory buffers, and other memory areas take up a large chunk of the already limited address space, leaving roughly 2 gigabytes for the applications running on the machine – 2 gigs which also are shared between all of the programs running.

Physical Vs. Virtual

A physical address of a memory block is implicitly defined by its position within the memory chips, and the order in which the modules are inserted into the mainboard’s memory slots. They start at zero and go up to a specific maximum.

A virtual address, on the other hand, is what the CPU and hence the application program sees. They might be the same, but as a general rule, they are different. Virtual addresses are given on the fly, but there is a rule that every memory cell must have a unique virtual address, because all references to that cell are stored as the virtual address the application sees.

Modern systems like the X1000 or upcoming models can take more than 4 gigabytes of memory, but so far, the extra memory will never be used. Even in a 4 gigabyte system, there is memory that will never be touched because there is just no free address; and unfortunately, every byte needs to have its own virtual address, and no two bytes can have the same.

Unless…

Extended Memory Object

Extended memory objects (ExtMem) are a means to access memory beyond the 2 gigabyte barrier by applications that are written to make use of them. In a nutshell, an extended memory object is a chunk of physical memory that exists in a “nirvana” state somewhere in the memory of the computer without a virtual address of its own. The memory cannot be accessed by anyone or anything in this state. In order to access it, an application must map part of the object into its own virtual address space. This mapping does make a part of the memory represented by the ExtMem object accessible in a memory window in the application’s own address space.

There is no limit to the number of mappings an application can do. If needed, it can have several mappings active at a time, and add or delete mappings as required. The only restriction is that mappings must not overlap (either in virtual address space or in the memory object itself). Each mappings opens up a view into a part of the memory object, and, depending on how the mapping was performed, the application can read and/or write to the memory as if it were normal memory.

fig2A mapping is defined by the virtual address in application memory (which can be chosen by the application, or picked at random by the OS), the length of the map’s window, and the offset it maps to in the ExtMem object.

There are some caveats though. Most notably, the ExtMem object itself doesn’t have an address. In that sense it should be treated more like a file than a memory block. If an application wants to have permanent references to memory in the ExtMem object, it needs to store them by offset, just like it would with a file. The first offset is zero, so to address the 1000th byte in the memory block, the application needs to reference it by the offset of 1000. Obviously, this offset must be calculated against the base of the mapping’s offset; just like in a file, reading a part of the file into a buffer makes the first byte read the offset zero in the buffer.

As an example, consider the following situation. We want to access byte 3000 of the ExtMem object. We created a mapping that has length 4000 and starts at offset 2000. The resulting address for our byte would be the base address of the mapping plus 1000, since the offset of the beginning is already at 2000.

Downsides of the ExtMem system

If you think now that this all sounds suspiciously like bank switching, then you are right. The method has been used way back in the Home computer age, and even earlier. The Sinclair ZX Spectrum 128K was equipped with twice as much memory as the Z80 CPU could address; the upper 16k of the machine could be swapped between different chunks of the rest of the memory. Similarly, the Commodore 64 used bank switching to address a larger memory than its 6502 CPU could handle. It was the only possibility at the time to add more memory.

This method we employ now is basically the same (with a bit more added comfort).

Obviously, the method is a compromise. A “real” 64 bit system would be better, and much more transparent to use. However, as I already outlined in the beginning, there is a lot of work involved to make AmigaOS 64 bit compatible, and with the method of ExtMem objects, breaking the barrier is possible now as opposed to years down the road.

Who can benefit from ExtMem objects?

Well, every application that, in some way or the other, has to cope with large amounts of data. Even if the dataset is only potentially large (like, for example, a text editor), using an ExtMem object has its advantages. The text editor (or word processor), by its nature, only presents a small subset of the text it is editing to the user. Likewise, a movie editor would only need to have access to a few frames in order to show thumbnails of the movie on a timeline, or display a single frame that the user is working with.

Another example is RAM disk. Plans are currently underway to update the RAM disk to make use of the ExtMem object interface, allowing out-of-the-box usage of those normally unassigned memory blocks without draining the valuable main memory. Since (depending on programmer setting) memory blocks can even be allocated “on-demand” instead of ahead of time, this will make RAM disk have an even lower footprint, on top of making it possible to store larger amounts of data than ever before in it.

It needs to be said that the ExtMem system doesn’t require memory beyond the 4 gigabyte bounds. It can work with normal memory as well, even though that is not its purpose.

So, as you can see, a good number of applications have a natural tendency to only access a very small subset of their memory at a given time. All of these are good candidate for using ExtMem objects to break the memory barrier.

FUSE and NTFS for AmigaOS

280px-FUSE_structure.svgFUSE is short for Filesystem in Userspace. FUSE was created to enable non-privileged users to run file systems outside of the kernel which is a big deal for Unix-like operating systems. In AmigaOS, everything runs in userspace so FUSE is not nearly as important for Amiga users. What makes FUSE valuable is all the file system implementations which use FUSE such as NTFS, ext2, ZFS, etc.

The Amiga Operating System implementation of FUSE has been realized via a project called Filesysbox by Leif Salomonsson. A special thanks goes out to Leif for allowing his hard work to be utilized.

Amiga programmer extraordinaire Fredrik Wikström was then commissioned to port Filesysbox over to AmigaOS. Fredrik took the original code and updated it to AmigaOS 4.1 standards. This work included utilizing advanced DOS features such as object notification and the new file system API which seeks to completely avoid the esoteric DOS packet interface. Colin Wenzel is the main man behind the advanced DOS features.

Master_500pxIn order to test whether Filesysbox was working properly we needed a file system to go with it. NTFS-3G by Tuxera was chosen for this purpose. Fredrik also ported a full suite of tools to go along with NTFS itself.

Both Filesysbox and NTFS-3G are contributions being offered to registered AmigaOS users via AmiUpdate. The software licenses require that the source code be made available so registered users can download the matching source code from Hyperion’s web site in the downloads section.

blog_devIt is hoped that 3rd party developers will become interested in porting more file systems in the near future whether they are via the FUSE API or the new DOS file system API. The upcoming SDK will include everything you need. In the mean time, please feel free to utilize the provided source code and the AmigaOS support forum for assistance.

Finally, a big thanks needs to go out to the AmigaOS beta testing team for risking their hard drive partitions while testing NTFS-3G and Filesysbox. It is demanding and potentially destructive work that should not be taken for granted.

AmiWest 2013 AmigaOS Team

AmiWest2013-AmigaOS-Team1200AmiWest 2013 is now over and it was a heck of a lot of fun. We managed to grab a team photo this time.

From left to right in the front row sitting down we have Ken Wilde and Lyle Hazelwood. Next row back we have Bill Borsari, Flip LaFramboise, Trevor Dickinson and Tony Wyatt. In the back row we have Matthew Leaman, Val Marti, Paul Sadlik, Steven Solie and Alex Carmona.

A special thanks to Mike Brantley for taking the photo. Mike also took a lot more photos at the AmiWest 2013 show.

I think the big smiles on those faces says it all really.

I also took some time to update the AmiWest 2013 crowd on the current status of the Amiga Operating System which I will now summarize here:

  1. The netbook project initially announced at AmiWest 2011 has been cancelled. Below is an excerpt from an email to me from Ben Hermans dated October 10, 2013 on this matter.

    Despite best efforts by Hyperion and A-EON we were unable to get acceptable and stable conditions and terms from the Chinese supplier (price point, paying terms, required upfront, etc.)…

    The project was therefore cancelled in favour of a more future proof solution.

  2. A-EON Technology announces the Cyrus Plus Beta Test Programme. Follow the link for all the details and how to apply.
  3. Gallium3D Update
    • Software rendering completed
    • Working on the WinSys part of the implementation
    • Challenges encountered along the way:
      • Must be re-entrant, thread safe and multicore capable
      • Must run on a bare minimum system
      • Efficient
      • Possible to load non-Mesa and non-Gallium drivers
  4. X-Kernel Update
    • Task scheduler rewritten in C
    • Removed reliance on data structures (e.g. ExecBase task lists and ThisTask pointer)
    • Moving scheduler to run on auxiliary cores
    • All cores schedule tasks independently
    • Load balancing between cores
  5. AmigaOS 4.2
    • Depends on Gallium3D release
    • May or may not depend on multicore support
  6. AmigaOS 4.1 Update 7
    • Will be needed for Cyrus Plus product release
    • Consolidates all previous updates
  7. AmigaOS 4.1 Update 6
  8. FUSE and NTFS-3G
  9. New development team members since AmiWest 2012

We also had a chance to have a team meeting on Friday night in one of the hotel rooms while at the show. We had the usual Airing of Grievances and a lengthy discussion on where we are going and how to get there. At one point we were interrupted by an outsider who likened the gathering to a secret Masons meeting.

If you would like to come to AmiWest 2014 and join in the fun then keep October 24, 25 and 26 open. There is also a programming seminar planned for October 23 and 24. See you there!

An SDK Update (finally)

blog_devIt has been a long time coming but we finally got around to releasing an updated Software Development Kit (SDK) for the Amiga Operating System. You can download it from Hyperion’s server.

This SDK includes all the usual includes and autodocs you need to use all the latest released AmigaOS features. The AmigaOS Documentation Wiki contains all the higher level information you need and will continue to be updated to help explain everything. The wiki also has a new Frequently Asked Questions section where we will post the most common problems and solutions.

This SDK is also a tad incomplete because I ran out of time to prepare it before AmiWest 2013. Therefore, there will be another SDK update or two sometime after the AmiWest show which will include even more.

We will also try harder to provide an updated SDK much more regularly from now on. Thanks to AmiUpdate we now have a way to deliver all sorts of SDK updates as needed with minimal effort.

Support for the SDK is available from the official AmigaOS support forum. You may also want to give OS4Coding a try if you get stuck on something.

Have fun!

New AmigaOS Core Developers

blog_devWe are pleased to announce that we have joined the AmigaOS development team. We hope that we are able to contribute some good things to AmigaOS using our skills in coding (Frank) and graphics (Thomas).

The follow is a short description of us and our products.

EntwicklerX:
We are currently working full time, self-employed, developing our games on multiple platforms (AmigaOS, Android, iOS, Windows Phone, Xbox Indies) as EntwicklerX. For about 10 years we have worked together on various software projects in our spare time. The focus in the last 5-6 years was to earn some money with the small bonus that it has allowed both of us to live from it (not enough for a Ferrari but enough to have fun at work). A strict separation between design and programming logic helped us build our products in an effective way with our limited time. While Frank takes care of programming, Thomas builds the graphics. Our subsystem is so sophisticated that Thomas can create and test Layouts without the help of Frank and Frank can use this directly in his code. This saves a lot of time and nerves. Before this, Frank had to compile every time if Thomas wanted to move a graphic a few pixels. 😉

AmiBoing Games

Our Amiga platform AmiBoing is used to bring an online connection to our games for high scores and achievements and it is also used for distributing our games. With more than 200 Users we can say this is the leading online gaming community on the Amiga platform. 😉

avatarImago_small

Thomas:
I care about what the user sees, how users interact with a game, paint graphics, create the levels and take care of our website. I have invested a lot of time into understanding how to create themes for AmigaOS and am still learning. The seamless design of an operating system is very important to me and I hope to play a part in this within AmigaOS.

avatarGoos_small

Frank:
I try to bring Thomas’ graphics to life and love to get the maximum out of AmigaOS using any available techniques to optimize (e.g. compositing). In our projects, I take care of all the programming. Together with Thomas, I am working on the game play and new game ideas. I can do my part in helping the Amiga in all areas of coding and to help current developers.

We are a Team:
Even with the split of responsibilities we will usually work as a team because ideas and their implementation always occur together. We look forward to working with the existing developers and also contributing to any interesting discussions. We will do our best but please note that we are only human and have a finite amount of time to work on everything. Give us time to understand how things work within the developer team. 😉

Best regards and let us say thank you for adding us to the list of AmigaOS core developers,
Thomas “imagodespira” Claus and Frank “Goos McGuile” Menzel.

Some Links:
EntwicklerX: www.entwickler-x.de
AmiBoing: www.amiboing.de
Themes: www.amiboing.de/themes.php

M.A.C.E

ThemeScreenshot