dev builds
themes manual
device status forums
mailing lists
IRC bugs
dev guide

Rockbox mail archive

Subject: Re: Descrambling
From: BlueChip (
Date: 2003-08-09

There is a big ANTI-assembler movement here, so if my personal experiences
here are worth anything, you are likely to get told to go back to C.

HOWEVER... *I* on the other hand, think assembler is perfectly acceptable
and would love to be running your code :)

SO... Even if your code is rejected, please make sure you put it somewhere
that the assembler freaks here can download it :) Maybe you could attach
it to your next email?


Real Programmers use GOTO

At 13:09 09/08/03 +0200, you wrote: >Hi, > >Someone "complained" that the descrambling in rolo_load() was slow, so I >had a look at it. :) As divides on the SH-1 is fairly slow, having two per >descrambled byte explains a lot. So I first tried by replacing the two >divides with one multiply (basically use the "addr" calculation from >scramble.c instead). This halved the execution time. > >Then I rewrote the new version in assembler and halved the execution time >again. :) Moving it to the internal RAM cut another 20-25 percent. In >numbers, that means the execution time has gone down from 1.6 seconds to >0.3 seconds (32 ticks). There's one limitation though: the image can be at >most 256 kB large... Maybe that's one reason for the 200 kB limit imposed >by the Archos firmware? > >I also noticed that the code that really needed to be in the "top" RAM >wasn't much, so I moved that to the internal RAM too, so the .topcode >section could be removed. It means an additional 80 bytes of the internal >RAM is used (this includes the descramble code). Even if the ROLO stuff, >per definition, isn't executed much, I'd say it's worth it :) But what do >you think? Should I leave that in the patch? > >Also, before submitting it, I think I'll convert the checksumming to >assembler as well. It will only add a few bytes anyway, and only adds one >cycle per byte in execution time. > >Btw, while doing this, I noticed a potential bug in bitswap.S: a nop >should be added after the rts instruction. It isn't a problem with the >current code, but if it is changed, the bug could be triggered, I think... > >-- >Magnus Holmgren > >

Page was last modified "Jan 10 2012" The Rockbox Crew