[perl #17035] [PATCH] chr support
Dan Sugalski
>I realise that proper Unicode support is coming, but it may be a while
>to get here. We currently have ord() and it makes sense to have a
>chr() as well, so that's what my patch provides. Please apply, thanks ;-)
Done.
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
Peter Gibbs
> > In fact, I tried to change S0, and whatever S0 value is (I tried with
> > several values: "<", ">", "A", "0", " "), I always get a 60 as its
ordinal
> > value...
>
> I forgot to tell you: it doesn't work when I try to change S0 from the
test
> set. But when I try to put a
> set S0, "v"
>
> just before using the ord instruction, then I get the good behavior.
> Of course, I can't use the set, since the char in S0 can be anything in a
> real program...
This looks like a COW bug. Try the attached patch (untested).
--
Peter Gibbs
EmKel Systems
Steve Fink
Thanks, applied, with regression test.
Aaron Sherman
I'd like to start a dialog about the P[arrot|erl] interface on the
matter of converting low-level types. ord and chr are Perl functions for
doing two very specialized conversions, but I'm thinking Parrot needs to
provide a general-purpose number/[bit]?string conversion ala Perl's
pack/unpack so that all of the conversion functions for all of Parrot's
client languages can be written in terms of them.
Certainly sprintf, pack and unpack in Perl should use some underlying
tool of Parrot's, and not re-invent the wheel (though each of those will
obviously do heavy argument processing in a Perl-specific way, some of
which I've already done for sprintf).
Should these conversions be individual instructions (e.g. "uint2string")
or should there be a single-target "pack" analog in the PBC?
Pardon me, if I'm walking old ground, but please do point me to the
prior discussion.
--
Aaron Sherman <a...@ajs.com>
http://www.ajs.com/~ajs
Clinton A. Pierce
>I'd like to start a dialog
And since this thread is quiet, I'll throw some uneducated opinions on it
to help it along.
>about the P[arrot|erl] interface on the
>matter of converting low-level types. ord and chr are Perl functions for
>doing two very specialized conversions, but I'm thinking Parrot needs to
>provide a general-purpose number/[bit]?string conversion ala Perl's
>pack/unpack so that all of the conversion functions for all of Parrot's
>client languages can be written in terms of them.
I was kind of surprised to see ord as a core op when I was doing
BASIC. And had actually written my hack to go both ways (chr/ord) in an
early version of the interpreter.
>Certainly sprintf, pack and unpack in Perl should use some underlying
>tool of Parrot's, and not re-invent the wheel (though each of those will
>obviously do heavy argument processing in a Perl-specific way, some of
>which I've already done for sprintf).
>
>Should these conversions be individual instructions (e.g. "uint2string")
>or should there be a single-target "pack" analog in the PBC?
I like the idea of having a single pack/unpack instruction, with some kind
of argument mechanism to determine exactly how to pack. I don't know of an
analogue in other CPU instruction sets (except maybe BCD ops in 8086), as
they're typically not interested in something as high minded as some of
this is.
And while we're wishing, I'm certain I wouldn't want it as platform
dependant as Perl's pack() is. I'd like to be able to easily determine if
I'm working with native ints or some other kind of int. If I want to I'd
like to pack my ints to 16, 32, or 64 bits on a whim. Use BCD and BER and
any other strange encoding schemes I want.
And I want a pony, too.
Something else to throw into the discussion is whether we want to use a
template (at the PBC level) as pack does or not. My initial gut reaction
is no, because then we'd wind up with things like:
pack S0, "ccxxcc", P0 # where P0 is a PerlArray or something
And I'm not sure if 1. the pack target should be a "string" or not and 2.
if I really want to have to mess with a PerlArray just to do some
byte-shifting in PBC. But not using a template means having to possibly
execute lots of instructions to disassemble the source piece-by-piece, and
keeping this canned set of PBC around as a library to do common functions.
Then again, I drool at the prospect of doing an sprintf in PASM...
Aaron Sherman
> >Should these conversions be individual instructions (e.g. "uint2string")
> >or should there be a single-target "pack" analog in the PBC?
>
> I like the idea of having a single pack/unpack instruction, with some kind
> of argument mechanism to determine exactly how to pack. I don't know of an
> analogue in other CPU instruction sets (except maybe BCD ops in 8086), as
> they're typically not interested in something as high minded as some of
> this is.
Yeah, I'm leaning that way too.
> And while we're wishing, I'm certain I wouldn't want it as platform
> dependant as Perl's pack() is. I'd like to be able to easily determine if
> I'm working with native ints or some other kind of int. If I want to I'd
> like to pack my ints to 16, 32, or 64 bits on a whim. Use BCD and BER and
> any other strange encoding schemes I want.
That makes sense. While parrot's "pack" (I think something like
"convert" might make more sense) will be used to write the Perl version,
there's no reason for it to have the same constraints. In fact, perhaps
Perl's could use an overhaul while we're at it, but that's a subject for
p6l....
> Something else to throw into the discussion is whether we want to use a
> template (at the PBC level) as pack does or not. My initial gut reaction
> is no, because then we'd wind up with things like:
>
> pack S0, "ccxxcc", P0 # where P0 is a PerlArray or something
As you correctly point out, you don't want a string here. This isn't
aimed at being convenient to program in, but a good target for back-end
code generation (at least one level of back-end, there might be more).
So if we have something like:
pack S0, foo, bar
What are foo and bar. I think foo is some sort of enumeration for the
various pack operations (just and integer parameter in the PBC) and
bar's type is dependent on foo. So, for example:
set S0, ""
pack S1, PackSignedC8, P0[0]
concat S0, S1
pack S1, PackSignedC8, P0[1]
concat S0, S1
set I2, 0
pack S1, PackUnsignedC8, P0[2]
concat S0, S1
concat S0, S1
pack S1, PackSignedC8, P0[3]
concat S0, S1
pack S1, PackSignedC8, P0[4]
concat S0, S1
Woudl be roughly what you described above, assuming the enumerated
arguments PackUnsignedC8 and PackSignedC8.
> And I want a pony, too.
Darn, where's that "me too" key on these new-fangled laptop keyboards?!
:)
> Then again, I drool at the prospect of doing an sprintf in PASM...
I'm writing it in Perl6 now (all except for the low-level type
conversion) and it's a pain. There are so darn many special cases!
Peter Gibbs
pack/unpack functionality. Code is not optimised in any way,
and error checking is basically non-existent.
Opcodes are:
convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz
convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz
Currently supported types are:
0 = 8-bit
1 = 16-bit little-endian
2 = 16-bit big-endian
3 = 32-bit little-endian
4 = 32-bit big-endian
Aaron Sherman
> Attached is a sample implementation of a minor subset of
> pack/unpack functionality. Code is not optimised in any way,
> and error checking is basically non-existent.
>
> Opcodes are:
> convert Sx, Iy, Iz - pack integer Iy into string Sx per type Iz
> convert Ix, Sy, Iz - unpack integer Ix from string Sy per type Iz
Awesome, thanks! I'll get to writing a wrapper around that for ord, chr,
sprintf, pack and unpack just as soon as I get done with the overall
builtins mechanism tonight. I'll probably have something within a couple
days (hard to get time to work on it).
Of course, the same will have to be done for floating point, but this is
a major step forward.
Graham Barr
As well as supporting big/little endian specifically, should we support "native"
ie packed in the same endian as the machine the code is being run on.
Graham.
Peter Gibbs
> As well as supporting big/little endian specifically, should we support
"native"
> ie packed in the same endian as the machine the code is being run on.
Certainly. I think we would want also want native sizes, so we can
ask for short, int, long etc and get the platform's size and byteorder.
If the concept gets accepted, then we can start extending.
Nicholas Clark
I think we also want unsigned (ie zero extension of values shorter than intval
whereas the supplied code does sign extension of values shorter than intval)
I'd quite like to see 2 bits as well as 1 (binary) and 4 (hex), but I'm
not sure how useful they'd be in the general case, versus an op to unpack
arbitrary bit lengths, but these are really more use for a function that
unpacks to an array rather than 1 value.
Nicholas Clark
--
Even better than the real thing: http://nms-cgi.sourceforge.net/