At 11:21 AM 12/27/00 -0800, Damien Neil wrote:
> >On Wed, Dec 27, 2000 at 02:06:45PM -0500, Hildo Biersma wrote:
>I seriously doubt Perl will ever run on an architecture too small
>to provide a 32-bit type. I am certain it will never run on an
>architecture with no 16-bit type.
I'm reasonably certain that all platforms that perl will ultimately run on
can muster hardware support for 16-bit integers. I also expect that they
can all muster at least software support for 32-bit integers. However....
The issue isn't support, it's efficiency. Since we're not worrying about
loss of precision (as we will be upconverting as needed) the next issue is
speed, and that's where we want things to be in a platform convenient size.
I honestly can't think of any reason why the internal representation of an
integer matters to the outside world, but if someone can, do please
enlighten me. :)
>Furthermore, the fact that the standard declares a thing DOES make
>it true. If Perl is to be written in C, it makes sense that it
>require a compiler which at least pretends to conform to ANSI/ISO
>C. This is hardly an onerous restriction -- most compilers are
>compliant, with the exception of compilers for very-small embedded
>systems (ones where the total memory available is measured in bytes)
>and antiquated curiosities like the SunOS 4 compiler.
The issue isn't compliance, it's efficiency. gcc gets you 64-bit integer
ops on x86 machines, but that doesn't make them efficient...
>Can you name specific compilers which fail to conform to the standard
>in this (or other) regards, which Perl will need to support?
It wouldn't at all surprise me if a number of embedded platforms like
16-bit integers best. I couldn't name one for you, that not being my area
of expertise, but since I haven't yet seen a reason why they should be
excluded (at least not one that works for me) I'm not willing to not do it.
Things also cut the other way--there are, or may be soon, platforms for
which you want 64 or 128 bit integers, so if we're not stopping things on
the high end, I don't see a reason to stop them on the low.
> > That's eskewing efficiency to make sensible minimum guarantees. I'd
> > personally rather see the C compiler's native types be used, because
> > that's what the platform can do _efficiently_. Using larger types than
> > that harms perl's ability to perform well on small platforms.
>
>I am deeply dubious about Perl's ability to perform well on 80286
>(or equivalent capacity) machines under any circumstances.
I'm not. I can see perl performing rather well in a number of smaller
systems if bits of the interpreter are tuned for the platform. (Like
rewriting pieces in assembly, for example)
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
