Rockbox mail archive

• Next message: Daniel Stenberg: "Re: FAT32/defrag/BSOD question, feature comparison"
• Previous message: Chris Holt: "Re: Re[3]: USB version"
• In reply to: Blue Chip: "Re: Random numbers et al"
• Next in thread: Blue Chip: "Re: Random numbers et al"
• Reply: Blue Chip: "Re: Random numbers et al"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Blue Chip wrote:

First of all, I'm sorry if I was too hard on you. I apologize.

> However, something like qsort, might benefit immensely. Maybe a more
> selective approach would be appropriate?

Of course. No need to optimize code that doesn't need optimizing.

> By example: system.c is a true mystery to me.

Hehe, that file is a mystery to everyone (well, almost).

It sets up the interrupt vectors (yes, I know you know that). It makes
use of a Gnu linker feature mainly used for linking libraries, called
"weak aliases".

It declares interrupt handlers for all vectors, reserve_interrupt()
means that the vector will never be used, calling UIExx to handle it.
The default_interrupt() macro creates a weak alias to UIExx for the
vector, this alias can then be overridden by defining a function with
the same name elsewhere in the code.

Example:

default_interrupt (IRQ6, 70);

This declares a weak alias IRQ6, that by default points to UIE70(). The
vector table (vbr) is initiated with this weak alias.

In mpeg.c, the IRQ6 function is defined:

#pragma interrupt
void IRQ6(void)
{
     stop_dma();
}

Now the linker uses the "real" IRQ6 function for the vector.

It is just a way of not having to edit the vector table when using an
interrupt vector.

> Given the application that your current random number generator is used
> for, the code which you have, although an impressive generator, is
> (imho) unnecessarily complex and memory hungry.

You may be correct. You are very welcome to examine this further and if
you can provide a smaller generator with a decent period we are all ears.

> It was never my intent to offend - I don't TRY to make enemies. I will
> only defend myself when I am attacked.

Sorry if you felt attacked. I feel responsible for that and I apologize
again.

> Sounds far more interesting when put like that.
> Is the last (rejected) solution available to look at?

Not really, but is a simple lcd_invert_rect() call to create an inverted
line in the browser. A quite slow operation, especially when the line
isn't fitting exactly in an 8 pixel row.

If you really feel like doing some tricky code, try optimizing the
lcd_bitmap() code. We also want it to be able to draw bitmaps taller
than 16 pixels.

Or maybe optimize the lcd_write() code in lcd.c if you feel like hacking
some assembler. Every cycle counts in that one.

/Linus

• Next message: Daniel Stenberg: "Re: FAT32/defrag/BSOD question, feature comparison"
• Previous message: Chris Holt: "Re: Re[3]: USB version"
• In reply to: Blue Chip: "Re: Random numbers et al"
• Next in thread: Blue Chip: "Re: Random numbers et al"
• Reply: Blue Chip: "Re: Random numbers et al"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]