Re: new version of MAD

On Mon, 30 Jul 2001, Steef Boerrigter wrote:

> I started merging the differences, but find it difficult and time
> consuming as I worked on a mad.c which branched off of mc over two years
> ago. Moreover, you may not like the chances, which would render my work
> useless altogether.

 I see a small problem in that there's been some bugfixing in mad.c in
the mean time. Looking through my changes I find I:

 *) Added 'Alloc_idx_hint' and 'Mad_check_call_delay' to make it a lot

 *) Changed some (g_malloc, g_new) -> mad_alloc, g_strdup_vprintf() ->
mad_strdup_vprintf() etc.

 *) Added mad_strndup().

 And did some general code factoring. For more detail, see:

> The main features/differences are:
> - dynamic memory area handles (instead of static # 20000)

 Using realloc sounds nice. And a hash table would be really nice.
(Well, hash tables can't be resized efficiently but I don't think that
would pose a problem.)

> - Support for SGI Indy (and probably more RISC and or MIPS platforms)
> which need 8 byte aligned blocks for double variables.

 Sounds useful.

<...>  On intel x86 family,
> things are much easier as I found no such requirements whatsoever.

 All processors in the x8[68] family can read 16-bit WORDs (and larger
quantities) on an arbitrary offset but reading a 16-bit WORD that
straddles a BYTE boundary requires the processor to do two separate
reads. (And this hurts even though it actually reads a whole cacheline
every time the L1 cache has a miss. [Or something along these lines, ask
Terje 'mr x86 optimisations' Mathisen.])

> P.S.
> By the way, I'm sending you the full files as the 'diff -u' files are
> bigger than the original files and I don't want you to confuse these
> files with actual patches.

 The 'diff -u' files would be usefull. Or if you could give us the exact
version you changed so everyone could do the diff herself.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]