#51 OCC buffer sizes?

[Bryan Wagstaff]

In the section of the binders that store object names,
the names are often followed by some substring
of "ionInterpol". It makes me wonder if you are
wanted by the InterPol, the International Police.

My guess is that the old data in the buffer is not
nulled, or the entire buffer is written rather than
the used portion of the buffer. The model names are
read in properly, but it is difficult to examine the
file manually.

Here is a portion which demonstrates from file
\\gerbil\public\models\slc_w_nurbs.osf from 0x4d40 to
0x5010:

dngrgpa1 terpol
dngrhull terpol
ambientLight1
directionalLight1
directionalLight2
skydom Interpol
I80gpb
I80gpc Interpol
I215grpb terpol
I80gpa1 nterpol
I215grpc terpol
I215grpd terpol
acdgpb1 nterpol
I15gpb Interpol
I15gpc Interpol
dngrgpa nterpol
rdwkgpb nterpol
rdwkgpc nterpol
camera1 nterpol
cameraPath rpol

Enjoy!
Bryan.

[Bryon Hapgood]

Logged In: YES
user_id=120775

Don't worry about it: "Interpol" (very funny incidentally)
is probably some left over text called "Interpolation". The
reason this happens is in debug builds of the kernel I
erase all of memory to 0xFFFFFFFF. In release builds (for
reason of speed) I do not. Therefore, whatever was in
memory before I started (to the nearest 16 byte boundary)
will get written out with the name.

I honestly don't care about this right now.

Bry.

[Bryan Wagstaff]

Logged In: YES
user_id=34599

That's exactly what I thought (both 'I didn't overwrite for
speed' and 'it doesn't make a difference', but I just
thought it ought to be up here.

OCC is a pre-production tool and probably doesn't need to
save the extra half-dozen instructions of clearing the
buffer; but since the same library is used in the
performance-critical final product... well, there are
always tradeoffs.

I think that (Intel chips only) this condenses to one load
cycles and runs on the high-speed MSRs, so unless the out-
of-order core was empty, there would be two one cycles and
almost zero runtime penalty for clearning the block. Since
you have already expressed interest in using processor-
specific coding, you can use MOVDQA (move double quadword)
or MOVEQ (move quadword) to fill it up 8 or 16 bytes at a
time using XMM or MMX (respectivly)is a single micro-op.
You could have that followed by a LOOP to zero up to 64
bytes per core cycle(since LOOP can run at an internal
speed of 4x the clock speed in the out-of-order core) with
a single load step. Coupled with a PREFETCH (which would
be the third and final op in the three-op load), you would
not even take a hit in zeroing out a full page of memory.

The CPU would even get a warm fuzzy, saying "SOMEONE KNOWS
I EXIST!! They even care about me and figure out how to
program me. :)"

Of course you can argue 'why zero it out when you will just
overwrite it later?' and be correct. I just think anything
under one memory page should be cleared out since it is
practically free, and looks nicer when you just dump their
contents instead of stopping at a null.

Of course none of this would be an issue if you instead
just wrote zeros after you encountered the first NULL,
which would also work, and falls prey to the same arguments.

That's just some comments. In the grand scheme of things
it probably doesn't make a difference either way, but now I
feel better.

Also, I'm changing the priority to 'lowest' since that's
the level it should be assigned. It is a nice to have, but
something to note.

Maybe that -- or I just wanted to let you know that I can
grok IA-32. Or both.

bryanw