At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
>--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > At 08:02 AM 12/26/00 -0800, Benjamin Stuhl wrote:
> > >Thus spake the illustrious Dan Sugalski <[EMAIL PROTECTED]>:
> > > > For integers, we have two types, platform native, and
> > > > bigint. No guarantees
> > > > are made as to the size of a native int. bigints can
> > be
> > > > of any size.
> > >
> > >I'm not sure about the wisdom of not making any
> > guarrantees
> > >about int size, since that means that extensions have to
> > go
> > >through the same hoops perl5 has, dealing with
> > >"unspecified" behaviors (cf. fun with ANSI stdio). To
> > make
> > >life easy, we might want to ordain sizeof(p6int) >=
> > >sizeof(void *) && sizeof(p6int) >= 4.
> >
> > Perl will (well, should at least) automagically upgrade
> > to bigints if a
> > regular int overflows (Assuming that conversion's not
> > been forbidden by a
> > particular variable), so that's not going to be an issue
> > inside variables.
> > As for types presented to extensions, we can certainly
> > provide I8, I16,
> > I32, and friends.
> >
> > >On the other hand,
> > >this makes a port of the PVM to Palms and the like
> > somewhat
> > >harder (but would it be much easier to wedge them into
> > the
> > >standard PVM?). Also, can we please mandate
> > 2s-complement
> > >integral math? Perl 5 really always has, but can we
> > please
> > >make it official?
> >
> > Why? For variables, math is math--2+2=4 regardless of
> > whether you're one or
> > two's complement, or BCD-encoded, or use the EBCDIC
> > signed characters,
> > or... Mandating representations seems rather too
> > low-level to me, though if
> > you've got a good argument I'm OK with it.
>
>Mostly because it seems to be a requirement for intelligent
>integer-preserving maths (cf. PERL_PRESERVE_IVUV in perl5).
Fair enough, though I'm not convinced it's enough to mandate it. I'm not
sure if there are any non-two's complement machines out there anymore,
anyway, since it makes the hardware design easier. (I know some machines,
like the System/3x0 family and various VAXen have string math instructions
as add-ons, but that falls into the bigint category not in the core integer
support)
> > > > For floats, we also have two types, C double and
> > > > bigfloat. No guarantees to
> > > > the size or accuracy of the double. bigfloats can be
> > of
> > > > any size.
> > >
> > >Floating point is even harder, and will require a lot of
> > >build-time checks anyway.
> >
> > The big issue I have with floats is that bigfloats will
> > be more precise
> > than regular floats/doubles, and so downconverting will
> > lose data, which I
> > don't like. Other than that, because floats should
> > autoconvert like ints, I
> > don't see any problem. (Not to say there isn't one, just
> > that I don't see
> > it... :)
>
>My question here is whether each supported platform is
>going to need to provide its own overflow
>detection/autoconversion decision routines, since the
>portable part of perl6 will have now idea how far it can go
>with native numbers.
Yes, they will. Each chip family, at least. I'm thinking we'll have a
generic CHECK_OVERFLOW macro that's redefined on a per-CPU basis and
handled by whoever's doing the port for that system, with some generic
fall-back code. All the CPUs I have experience with can autodetect this,
though it's an odd set. (VAX, Alpha, 6502, 680x0, 880x0, and System/3x0
series chips) I don't know if Sparc, MIPS, ARM, or x86 do it, but I'd
assume so.
Yeah, it means some assembly for speed, but I'm OK with that.
> > > > Strings can be of three types--binary data, platform
> > > > native, and UTF-32.
> > >
> > >"platform native"?
> >
> > ASCII, EBCDIC, 16-bit chars, whatever. I'd rather not
> > deal with
> > variable-length characters at all, so things like UTF-8
> > and friends aren't
> > really on the list. (Though they could be with the regex
> > engine dealing
> > with them in UTF-32 format)
>
>But why is perl6 messing with them, since it has no idea
>what they mean?
But it does, though--the character constant 'A' becomes *something* on each
platform. Might be 8-bit ASCII or EBCDIC, might be some 16-bit wide
character, might be UTF-8. Who knows, but the underlying runtime library
for the platform can manage it, and if it can't, then whoever's managing
the port can fall back to whatever they like.
> > > > No, we are not messing around with UTF-8 or 16, nor
> > are
> > > > we messing with
> > > > EBCDIC, shift-JIS, or any of that stuff. Strings can
> > be
> > > > stored internally
> > > > that way (and the native form might be one of them)
> > but
> > > > as far as the
> > > > interface is concerned we have only three. Yes, this
> > does
> > > > mean if we mess
> > > > with strings in UTF-8 format on a non-UTF-8 system
> > > > they'll need to be fed
> > > > out in UTF-32. It's bigger, but we can deal.
> > >
> > >The issue with UTF-32 is that we'd need to write an
> > entire
> > >string-handling library, while quite a few modern
> > platforms
> > >have _wstr* or equivalent.
> >
> > I'm not sure there's much in the way of string handling
> > that we need to do
> > that's not perl-specific. It's also not all that much
> > work anyway and,
> > while it is stuff we'll need to do, the benefits seem
> > worth it.
>
>The only issue is that the CRTL's versions may be in
>hand-tuned assembler, and perl6 will be doing a _lot_ of
>strlen()s, I expect. But with good compilers, I suppose,
>its an open question on how much performance one really
>gains from hand assembly.
Gack. I certainly hope we do *not* do many strlen()s at all. C's 'string'
handling is one of the most evil, error-prone, lame excuses for working
code that I've ever seen. Almost all of what perl 6 will be doing for
length checking is reading in the length field for a scalar. Far safer and
faster. (And makes dealing with variable length character data easier too,
though I'd rather not do much of that, either) I wouldn't be that surprised
if we don't actually do any strlen()s at all in the core.
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
