The Upward Spiral

Have you remembered about page boundary crossings? They can add one cycle to your carefully timed code and are a real pain to avoid in unrolled kernels like this.

 

Chris

Have you remembered about page boundary crossings? They can add one cycle to your carefully timed code and are a real pain to avoid in unrolled kernels like this.

 

My suggestion for avoiding page-crossing nastiness is to arrange the kernel so that each bunch of stuff is page-aligned. If I have two groups of eight pieces of code, each about 120 bytes long, I'll put one group in the first half of each of eight pages, and the other group in the second half of those same eight pages. Wastes a little space, but not too much.

Have you remembered about page boundary crossings? They can add one cycle to your carefully timed code and are a real pain to avoid in unrolled kernels like this.

 

Chris

That one bit me while I was working on MM last weekend. I wasted about 4 hours trying to track down why the dragon's body started to fly faster than his wings

Have you remembered about page boundary crossings? They can add one cycle to your carefully timed code and are a real pain to avoid in unrolled kernels like this.

 

Chris

 

Thanks to the wonders of M4, and my total inability to perform long strings of arithmetic, and the joys of Stella, ... no

 

I was worried about it at first. In fact, you'll see an earlier blog screenshot where I was having problems on I think it was line (4,1) because of boundary crossings. There's only exactly one branch in the kernel -- on every second line -- and it's always taken (i.e. one of two branches are taken, so there's always a branch). The thing is, I set all my timings experimentally, running in Stella and deciding to add (n) cycles to each line with a bunch of special-case code like

if [ $1 == 7 && $2 == 0 ]
   SLEEP 8
endif

When M4 unrolls the loop, it does so with the variables $1, $2, and $3 set to the triplet, the offset within the triplet, and odds-or-evens (I have an example in one of past couple days' blog entries)

 

To make sure that minor code tweaks never do "nudget" where the boundary falls, though, I did put in this monstrosity:

jmp draw_rows
align 256
draw_rows:

 

Thus guaranteeing that whatever I do to the prior code, the kernel will always start on a page boundary. That's fine for now (development); once I declare a "code freeze" I could probably compress out that gap and deal with the consequences once, but right now the rest of the kernel's in a state of flux, too, and I'm not as pressed for space now as I shall be, shortly.

 

Incidentally, the kernel (unrolled) for tile drawing is weighing in around 1K, which is terrible because it constantly accesses map data, thus preventing me from sharing it across memory banks. (I can't do mad amounts of bankswitching within the kernel).

 

Here's the frightening but plausible thing I thought of ... splitting map data such that the data referenced during the first 6 scanlines was found always in bank 1, the next 6 in bank 2, the next 6 in bank 3, the last 6 in bank 4. But even with Perl compiling my data and M4 composing my code, I'm not insane enough to want to split the data up like that. It'd be a logistical nightmare, more so than it is already. So i've to bite the bullet and duplicate about 1kiB of "identical" (or nearly so) code in each memory bank that's to display tile-based data. Including support stuff, that's really closed to 6 pages, possibly more, of the 16 pages banked in. 10 pages isn't a lot of space, especially given that there are alignments needed for several data