Mail Archives: djgpp/1996/11/29/07:45:05
> > > There shouldnt be any problem running 16 bit data in 32 bit form.
> > > I don't understand what is your problem here??? How did you get
> > > the feeling that your program would actually get slower if you use
> > > 32 bit data instead of 16 bit data.
> >
> > Well, my logic is this: You have to move 2x as much data around; this
> > means your L1 cache fills up 2x as fast. This is not good.
>
> Hmmm...I would think that if about 20 people told me one thing, and I
> was the only person considering the other, that I would be wrong... ;)
<grin> I just figgured that because nobody was able to justify what they
were saying I should press on :)
> Now, here's the difference: if your accessing 32 bit data, and its in
> the cache, you get it for free (ie: 0 cycles), if you access 16 bit
> data, you have a size prefix (1 cycle).
I have been able to confirm that a size override for word sized data does
in fact cause a 1 cycle stall on Pentiums... (I went and looked it up) :)
But (not that you were disputing this), this is a quote from the intel
web site:
> With 8-bit operands, try to use the byte opcodes, rather than using
> 32-bit operations on sign and zero extended bytes. Prefixes for operand
> size override apply to 16-bit operands, not to 8-bit operands.
This was confusing, and needed to be made clear.
The final story: avoid short ints, regular ints are just peachy, and keep
on trucking with those chars.
Have I got this clear?
Peace
===[ Gabo / [ABC] : gaminer AT undergrad DOT math DOT uwaterloo DOT ca ]===================
Latest ABC Shogi: http://www.undergrad.math.uwaterloo.ca/~gaminer/shogi.html
"What Greenpeace spends in a year General Motors spends in four hours" -Moby
- Raw text -