4 Apr
2006
4 Apr
'06
7:47 p.m.
Michael B. Brutman wrote:
But, that's why HLL's are at such a disadvantage in this case!
Because they *can't* efficiently do these things.
OTOH, I can stuff a byte of flags into a register and,
by carefully considering how they are packed in that byte,
(heck, *I* decide the packing order!), I can sequentially
unpack the flags AS I NEED THEM in a line of code, etc.
do_something
ADC A,A ;shift MSB into cy, old cy into lsb
JP C,omit1
do_something_conditional_on_that_flag
omit1: do_something
ADC A,A ;next flag into cy, retrieve previous to lsb
JP C,omit2
something_conditional_on_flag2
omit2: ...
And, when I am done, I still have the original flags *unaltered*
without having to store them in memory to preserve them (as
would be necessary if I loaded-masked-and-tested).
I've yet to see a C compiler smart enough to do these things :>
> It's
really difficult to make the transition to resource-rich
> applications... it's hard not to count clock cycles, measure stack
> penetration (do people even *know* how deep the stack needs to be on
> modern
> desigs? Or, do they just keep bumping it up until the code works??),
> pare
> data down to the smallest necessary size, etc. (I still cringe every
> time I
> use an int for a bool! :>)
I wouldn't want to waste 32 bits for a simple boolean data type. But I
also wouldn't try to cram 8 booleans into a byte. The and'ing and
or'ing you have to do isn't worth the space savings, unless your data is
primarily on/off. Everything depends on the situation.
Of course!