At 12:41 PM 1/2/01 -0500, Uri Guttman wrote:
> >>>>> "DS" == Dan Sugalski <[EMAIL PROTECTED]> writes:
>
> DS> I was thinking of chips like the 68008, which had a 16-bit data
> DS> bus. While the native word size was 32 bits, fetching one took two
> DS> trips out to memory. Done automagically for you by the chip's
> DS> circuitry so you didn't have to worry, but 16-bit integers were
> DS> markedly faster to use than 32-bit ones.
>
> DS> Nobody may do that any more, but I think extra pins off a chip
> DS> still cost something, so they may still do it.
>
>but that is all transparent to the software as you point out. thinking
>about memory cycles here is premature optimization.
No, I don't think so. In this case, the natural word size really is 16
bits, regardless of what's transparent to the programmer. (Just as 32-bit
integers seem fastest for many things on Alphas, despite the fact that it's
a 64-bit processor) All I want to do is make sure there are real-world
cases of smallish integer machines that perl may want to run on, and I
think that's been established now.
>so let's stop worrying about embedded stuff now. if we make the primary
>integer size a config option with proper defaults, that should allow any
>embedded ports to do their thing. worrying about saving a bus cycle in a
>perl program is kinda silly.
I think you'll find that's not the case, really. While it's a little early
to grovel over bits of the code, now is *exactly* the time to make sure the
core architecture's got no overt gotchas in it.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
