Low-level coding part 1: Pointers

Introduction

So you wanna be a low-level programmer?

When I was starting out programming I was in awe of low-level coders and definitely felt insecure about my own potential in that area . While I felt I could sort of feel my way through high-level code, the requisite information and skills for low-level coding (assembly, OS API, low-level C/C++, etc.) just seemed so esoteric and random – I didn’t know how anyone could figure that out.

20 years later I can say… well, low-level coding IS esoteric and random! It’s just a big grab bag of random weird knowledge. The important thing I realized though is that nobody just uses their intuition to break into it. You wanna program in a new operating system or on a new kind of processor? You have to just get an instruction manual.

The power of profiling

The other day I noticed that Wii Plasmacore (WiiCore) was using an awful lot of memory just loading a super-simple Slag program. I finally did some runtime profiling on the VM – just printed out how many memory allocations were being made at various points – and found some interesting results.

Turns out that loading a Slag program took 37,000 memory allocations and about 22 MB. Interestingly enough those two figures aren’t related. The bulk of the 37,000 allocations – and a fairly small amount of corresponding memory – came from an area that was fairly innocuous in my mind: the generation of complete signature strings for all the methods (e.g. “Global::min(Int32,Int32).Int32″). I coded up a different system for the method signatures (which are only needed for hooking up native callback functions with the appropriate Slag calls) and cut the number of allocations down to 12,000.

About half of the memory usage came from allocating a default 10 MB of “fast heap” (which I quickly toned down to 2 MB for the Wii); most of the other half came from a mix of the 3-dimensional aspect call lookup table ([reference type index][aspect type index][method index]) – and from the following bug in my ArrayList class:

data = new DataType[ count * sizeof(DataType) ];

Yeah… the array size is calculating the number of bytes when it should be the number of elements. So say type “DataType” is 8 bytes per value and we wanna allocate 100 values. We need 800 bytes, but this bug would give us 6,400 bytes instead. Each array was sizeof(DataType) times bigger than necessary!!

So now I’m getting 12,000 allocations using 6.3 MB. Much better! There’s still one more thing that can be significantly improved: I notice there’s a lot of small 8, 16, 32, and 64-byte allocations that end up taking 64 bytes per allocation with the built-in memory manager – first off the Wii wants most things to be 32-byte aligned (for the benefit of Direct Memory Access circuits that bypass the CPU) so anything less than 32 bytes gets rounded up to 32. Second the memory manager use an extra 16 bytes per allocation, so of course that gets rounded up to another 32. My current project then is to work up a little memory manager that more efficiently handles small allocations.

Wiidiculous

So I’m working on porting Plasmacore to the Wii. It’ll be used first in RiverMan Media’s WiiWare game MadStone. Anyways, I got stuck for 3 days on a heinous bug.

On the PC folder emulating the DVD drive, all content has to be stored in a folder “content2″ or “content3″ etc. – the number is arbitrary. Everything was working at first but then as soon as I changed and recompiled the Slag program the Wii devkit would freak out. Basically it would load some files, but other ones would cause it to freeze for around 10 seconds and then come up with a “Fatal Error” of some kind. I eventually moved all the files to a new folder – e.g. “content4″ instead of “content3″. Everything would work fine – UNTIL I edited the program and then it would just stop working. It was the strangest thing, and all my debugging and tracing turned up nothing. WELL… apparently a locked file totally screws up the DVD emulator. So the problem was that each time I changed something I would leave Vim open like I normally do – its hidden swap file was the culprit!

Hello World!

# hello.slag
class Hello
  METHODS
    method init:
      println( "Hello World!" )
endClass