JeLlyFish.software at gmx.net
Wed Oct 26 12:26:56 CEST 2005
On Wednesday 26 October 2005 10:06, Micha Nelissen wrote:
> Vinzent Hoefler wrote:
> >>Oh right! Something like a masked compare or so...probably not
> >>implementable in an efficient way indeed I guess.
> > Whatever you call efficient. A simple memory compare won't do, as
> > others already pointed out, and everything else depends on the
> > actual layout of the structure.
> Your structure is very short, code length will explode for larger
Yes, of course, especially when the structures do not contain large
fields of contiguous data which can be compared with "repe cmpsd" or
whatever equivalents other processors besides x86 might have.
But that would - of course - also be the case, if you write your own
comparison function in the higher level language (without specialized
> It's inefficient compared to "REPE CMPSD" with proper
> context, this is only a few lines.
Precisely. But that's just the way it has to be, there's no way around
it unless you assume that unused padding bits/bytes always have the
same value (which could be a wrong assumption in quite a lot of cases -
try reading such values from an external hardware device with unused
connections left floating).
For these sort of things, it will be as inefficient as it can get either
way, no matter if you let the compiler do the work or if you come up
with your own comparison function.
> > andl $56, %eax
> > andl $56, %edx
> > cmpb %al, %dl
> > je .L49
> > .L42:
> > movl %esi, %eax
> > popl %edx
> > popl %ebx
> > popl %esi
> > ret
> What does this part do btw? Compare lengths?
No, it masks off the unused bits (Padded_Record.A is located in the
middle of an octett like this XXX---XXX) and then does the comparison,
I would suppose. It falls through directly to the exit code (restoring
saved registers, and then returning the value) at .L42 if the
comparison already fails. I really meant it, when I wrote, that the
structure I told the compiler to build up is quite nasty. ;-)
public key: http://www.t-domaingrabbing.ch/publickey.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
More information about the fpc-pascal