Re: new version of MAD

Hi Bjorn Eriksson,

>  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.)
You mean using a hashing table would be nice to tackle the slooooowness
of MAD when it goes over ~10000 handles?

> > - Support for SGI Indy (and probably more RISC and or MIPS platforms)
> > which need 8 byte aligned blocks for double variables.
>  Sounds useful.
Mad crashes on the very first alloc. So useful is an understatement.
"Vital" is more appropriate ;-)

>  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
This is useful information. I conclude from it that even on the intel
architecture alignment is desired if we want to improve the speed of our
program being debugged.

>  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.

Uh oh, didn't you get the mad-new.[ch] as attachments?

In that case either my mailer is sick or the attachments are cut off by
the mailing list handler.



Drs. S.X.M. Boerrigter
RIM Laboratory of Solid State Chemistry, University of Nijmegen
Toernooiveld 1, 6525 ED  Nijmegen, The Netherlands
Telephone: (+31)-(0)24-3652831    Fax:(+31)-(0)24-3653067
email: sxmboer sci kun nl
Quidquid latine dictum sit, altum viditur.
"Unix was not designed to stop people from doing stupid things,
 because that would also stop them from doing clever things." --Doug
Murphy's law: Anyt<Warning: Mail system error: Unexpected End Of File>

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