From: Blue Chip <cs_bluechip_at_webtribe.net>
Date: Mon, 07 Apr 2003 02:39:25 +0100

Sorry for my newbie ignorance.

>Our coding guidelines don't forbid different layouts. We feel that we have
>better things to do than trying to make the code look uniform. We have a
>few guidelines, but not many about formatting.

Is there a top-down of this code anywhere - a tree of how everything hangs
together? Please tell me that I didn't miss it in the docs dir. - that
would be embarrasing!

Where can I find the BEST info on the thread handler and other such low
level things - it seems silly to play with code until I understand the
basic premises upon which it works.

>># The random number generator appears to be a horribly complex and memory
>>hungry block of code - is there any reason why this monstrous algorithm
>>was chosen over the classic "X <- (aX + c) mod m"?
>
>Yes, we wanted a very good random number generator.

I am very interested to hear what the advantages to this complex rand()
generator are. As I read, all it does is extend the period, but given your
playlist randomize routine, this offers no additional benefits!? What
am I missing???

>>If not, please say and I will forward my random number class (2 minutes
>>to convert back to C again) and documentation (including biblio) to some
>>relevant person. The memory, codespace and execution time could ALL be
>>greatly improved by this change.
>
>Yes, we would maybe save 2-3kbytes.

riight, I have been working with DVD firmware for the last year or two
where 3K of memory is considered VERY valuable.

>I'm not sure that the execution speed gain would be noticeable at all.

Yes, again, this is a kickback of having to be anal about writing efficient
code. The philosophy I have been forced to work with in the past can be
summed up by the UK expression "count the pennies and the pounds will take
care of themselves."

>># Would anybody entertain a rewrite of the core libs (memset/strcpy/etc)
>>in assembler - it appears that this would make a notable difference to
>>the speed of the codebase? Plus ASM is my language of choice.
>
>We want as little assembler as possible. And I'm not sure that you would
>gain that much execution speed anyway. We would rather want easily
>maintained code.

I was not aware that your core libs were still undergoing changes. You are
right, it is much easier to work in C until you are sure you will not be
changing things. I shall look at the bug list tonight and try to fix any
problems left in the core libs for you :)

>/Linus

L8rz

Bc

(( O.T.: If anyone here has an ESS based DVD player - you owe it to
yourself to take a look at http://groups.yahoo.com/group/OneFirmwareForAll
and/or http://groups.yahoo.com/group/Mipsx_src for all your freebie
firmware needs ))
Received on 2003-04-07