Question about the following code.
+INTVAL
+string_compare(STRING* s1, STRING* s2) {
+if (s1->encoding != s2->encoding) {
+if (s1->encoding->which != enc_utf32) {
+s1 = Parrot_transcode_table[s1->encoding->which][enc_utf32](s1,
NULL);
+}
+if (s2->encoding->
On Tuesday 09 October 2001 02:11 pm, Michael Maraist wrote:
> I saw another post on the improvements provided by the simple
> modification of:
>
> goto *array[*code];
>
> lbl1:
> # do stuff
> goto *array[*code];
> lbl2:
> # do stuff
> goto *array[*code];
> ...
> end:
> return;
>
> And th
At 06:08 PM 10/9/2001 -0700, Steve Fink wrote:
>Quoting Dan Sugalski ([EMAIL PROTECTED]):
> > Okay, here's a quick rundown on PMCs and how we're handling opcodes called
> > on PMC registers. (This is mildly different than what's gone in the
> past, FWIW)
> >
> > Every PMC has a set of static type
At 12:58 AM 10/10/2001 +0100, Simon Cozens wrote:
>On Tue, Oct 09, 2001 at 10:37:22AM -0400, Dan Sugalski wrote:
> > On the other hand, I'd really, *really* rather not have Unicode
> > constants in anything other than UTF-32
>
>That's a bizarre decision; I'm sure you mean UCS-4 by that.
Nope, I m
On Wed, Oct 10, 2001 at 12:49:50AM +0100, Tom Hughes wrote:
> Attached is a patch to add string comparison ops, along with the
> necessary infrastructure in the string code.
I see no tests *or* documentation. Come on, Tom, you should know
better than that. :)
--
\let\l\let\l\d\def\l\a\active\l~
On Tue, Oct 09, 2001 at 11:50:55PM +0200, Benoit Cerrina wrote:
> It is clear that PMCs are object but does the acronym has a signification?
Parrot Magic Cookie.
> Where can such things be found.
In the documentation I'm in the middle of writing. :)
Simon
--
Pretty, smart, sane:Pick two.
On Tue, Oct 09, 2001 at 10:37:22AM -0400, Dan Sugalski wrote:
> On the other hand, I'd really, *really* rather not have Unicode
> constants in anything other than UTF-32
That's a bizarre decision; I'm sure you mean UCS-4 by that. I
don't think UTF-32 can address outside of the BMP, but I can't
q
Attached is a patch to add string comparison ops, along with the
necessary infrastructure in the string code.
The current behaviour is that if the two strings do not have the
same encoding then both are promoted to UTF-32 before comparison
as that should generally preserve information.
Tom
--
Benoit Cerrina:
#Excuse me,
#It is clear that PMCs are
#object but does the acronym
#has a signification? Where
#can such things be found.
PMC eq "Parrot Magic Cookie"--a PMC is an opaque Thing whose actual
value you don't care about.
Excuse me,
It is clear that PMCs are object but does the acronym has a signification?
Where can such things be found.
Thank you
Benoit
At 10:29 PM 10/9/2001 +0100, Tom Hughes wrote:
>I havn't added the A prefix because I'm still not clear what
>encoding those are supposed to map to. I can understand the
>following mappings:
>
> N => enc_native
> U => enc_utf32
>
>but what is A supposed to map to exactly? or is the assembler
>
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> utf8 and utf16 are both variable length encodings for space reasons.
> There's not much reason to space-compact something then expand the heck out
> of it. On the other hand, I'd really, *really* rather not have Un
At 03:59 PM 10/9/2001 -0400, Michael Fischer wrote:
>Declaring that static void * array[] = {...} in a header,
>produced by process_opfunc.pl. Dan, Michael, Bryan,
>care for me to revamp my patch to print out a goto
>table like the above?
Sure, if it works and doesn't get in the way of doing it d
At 03:03 PM 10/9/2001 -0500, Gibbs Tanton - tgibbs wrote:
> > At 07:03 PM 10/8/2001 -0500, Gibbs Tanton - tgibbs wrote:
> > >This looks good.
> > >
> > >Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use
>utf32_t and
> > >then mask off the lower 8 or 16 bits? We can still have utf8_t
On Oct 09, Michael Maraist <[EMAIL PROTECTED]> took up a keyboard and banged out
> > void
> > runloop(int**code) {
> > static void* array[] = { &&op_end, &&op1, &&op2 };
> >
> > start:
> > goto *array[*code];
> >
> > op1:
> > foo; goto start;
> >
> > op2:
> > foo; goto start;
> >
> > op_end
> At 07:03 PM 10/8/2001 -0500, Gibbs Tanton - tgibbs wrote:
> >This looks good.
> >
> >Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use
utf32_t and
> >then mask off the lower 8 or 16 bits? We can still have utf8_t be
defined
> >as char to allow sizeof to work right and we can do siz
On Oct 09, Michael Maraist <[EMAIL PROTECTED]> took up a keyboard and banged out
> > void
> > runloop(int**code) {
> > static void* array[] = { &&op_end, &&op1, &&op2 };
> >
> > start:
> > goto *array[*code];
> >
> > op1:
> > foo; goto start;
> >
> > op2:
> > foo; goto start;
> >
> > op_end
The test for cmod_i was using the 'mod Ix, Ix, Ix' form which compiles
into the mod op, not the cmod_i op, hence wasn't testing what it thought
it was. I've patched this below.
The following ops also do not yet have tests, some because they are throwaway,
some because they're waiting on other op
At 12:54 PM 10/9/2001 -0400, Bryan C. Warnock wrote:
>We are going to need to come up with a better strategy than a DO_OP macro,
>though.
DO_OP can certainly be a placeholder we rip out and replace as part of the
configuration process. We're not limited to C's macro system if we don't
want it.
At 02:11 PM 10/9/2001 -0400, Michael Maraist wrote:
>Oh by the way.
>
>500M ops in 15 seconds is 1.02 Billion parrot ops / second. This isn't
>too shabby on a mere 466MHZ machine.
The performance is impressive regardless, but isn't that 33M parrot ops/sec
rather than 1.02G ops/sec?
>Pure-mathe
> void
> runloop(int**code) {
> static void* array[] = { &&op_end, &&op1, &&op2 };
>
> start:
> goto *array[*code];
>
> op1:
> foo; goto start;
>
> op2:
> foo; goto start;
>
> op_end:
> return;
> } // end code
> w/ code=1000, loop_cnt = 5,000,000
> gcc -O3 speeds.c
> --
> switcher tim
In message <[EMAIL PROTECTED]>
Dan Sugalski <[EMAIL PROTECTED]> wrote:
> At 07:03 PM 10/8/2001 -0500, Gibbs Tanton - tgibbs wrote:
> >This looks good.
> >
> >Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use utf32_t and
> >then mask off the lower 8 or 16 bits? We can still
On Tuesday 09 October 2001 12:05 pm, Paolo Molaro wrote:
> > It improved the speed of non-optimized code, because you didn't jump to
> > the end of the switch simply to jump back to the loop conditional. But
> > I didn't see any additional improvements with optimized code, because
> > the optimiz
Okay, I need to prefix this with a public apology. My initial reply was
cranky and unprofessional
At 01:48 AM 10/8/2001 +0530, V Vinay wrote:
>Dear Dan,
>
>You are doing a wonderful job and my intension is not to pass judgements on
>any one's technical abilities on this list. We have a bunch of
At 12:13 PM 10/9/2001 -0400, Michael Maraist wrote:
>The key was &&lbl which returns the physical address of the a jumpable
>label. This is highly gcc-specific, but given that we can use
>#ifdef's I don't see a problem with it. :)
No #ifdefs here. Instead the contents of the DO_OP macro should b
On Tue, 9 Oct 2001, Dan Sugalski wrote:
> At 01:20 PM 10/9/2001 +0200, Paolo Molaro wrote:
> >On 10/07/01 Bryan C. Warnock wrote:
> > > while (*pc) {
> > > switch (*pc) {
> > > }
> > > }
> If anyone wants an official ruling...
>
> DO_OP can contain any code you like as long as it:
>
> *)
On 10/09/01 Bryan C. Warnock wrote:
> > About the goto label feature discussed elsewhere, if the dispatch
> > loop is emitted at compile time, there is no compatibility problem
> > with non-gcc compilers, since we know what compiler we are going to use.
> > I got speedups in the 10-20% range with
At 10:49 AM 10/9/2001 -0400, Andy Dougherty wrote:
>In perl.perl6.internals, you wrote:
> >At 09:53 AM 10/8/2001 -0400, Gregor N. Purdy wrote:
> >>The thing that's making my brain itch right now is div. We cannot afford
> >>to do complicated things to the standard integer division, but you will
>
http://subversion.tigris.org/
In perl.perl6.internals, you wrote:
>At 09:53 AM 10/8/2001 -0400, Gregor N. Purdy wrote:
>>The thing that's making my brain itch right now is div. We cannot afford
>>to do complicated things to the standard integer division, but you will
>>have noticed that the nicer mod is based on floor-div (whe
At 07:03 PM 10/8/2001 -0500, Gibbs Tanton - tgibbs wrote:
>This looks good.
>
>Also, WRT the utf8_t, utf16_t, and utf32_t can we not just use utf32_t and
>then mask off the lower 8 or 16 bits? We can still have utf8_t be defined
>as char to allow sizeof to work right and we can do sizeof(utf8_t)*
At 10:51 PM 10/7/2001 -0400, Michael Fischer wrote:
>Ok, this is a big one. Over 500 line diff, plus a new module
>for parrot/Parrot.
Thanks a lot for this.
Dan
--"it's like this"---
Dan Sugalski
At 09:53 AM 10/8/2001 -0400, Gregor N. Purdy wrote:
>The thing that's making my brain itch right now is div. We cannot afford
>to do complicated things to the standard integer division, but you will
>have noticed that the nicer mod is based on floor-div (where C does
>truncate-div). Having floor-d
At 01:20 PM 10/9/2001 +0200, Paolo Molaro wrote:
>On 10/07/01 Bryan C. Warnock wrote:
> > while (*pc) {
> > switch (*pc) {
> > }
> > }
>
>With the early mono interpreter I observed a 10% slowdown when I
>checked that the instruction pointer was within the method's code:
>that is not a chec
On Tuesday 09 October 2001 07:20 am, Paolo Molaro wrote:
> On 10/07/01 Bryan C. Warnock wrote:
> > while (*pc) {
> > switch (*pc) {
> > }
> > }
>
Should have been "while (pc)". Oops.
> With the early mono interpreter I observed a 10% slowdown when I
> checked that the instruction pointe
On 10/09/01 Benjamin Stuhl wrote:
> Unfortunately, compiler tricks only work at compile time.
> They're great for static languages like C++ or C#, but Perl
> supports doing
>
> %CORE::GLOBAL::{'&print'} = \&myprint;
>
> at _runtime_. This is much to late to be going back and
> patching up any oc
--- Paolo Molaro <[EMAIL PROTECTED]> wrote:
[snip, snip]
> The problem here is to make sure we really need the
> opcode swap
> functionality, it's really something that is going to
> kill
> dispatch performance.
> If a module wants to change the meaning of, eg the +
> operator,
> it can simply req
On 10/07/01 Bryan C. Warnock wrote:
> while (*pc) {
> switch (*pc) {
> }
> }
With the early mono interpreter I observed a 10% slowdown when I
checked that the instruction pointer was within the method's code:
that is not a check you need on every opcode dispatch, but only with
branches, s
On Tue, Oct 09, 2001 at 04:03:13AM -0400, Michael G Schwern wrote:
> On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> > Questions, anyone? ;-)
>
> Will there be a test on this?
Plenty, I hope, but isn't that your perview? :)
--
fga is frequently given answers... the best are "Da
On Mon, Oct 08, 2001 at 06:36:32PM -0400, Dan Sugalski wrote:
> Questions, anyone? ;-)
Will there be a test on this?
--
Michael G. Schwern <[EMAIL PROTECTED]>http://www.pobox.com/~schwern/
Perl6 Quality Assurance <[EMAIL PROTECTED]> Kwalitee Is Job One
It sure is fun masturbati
40 matches
Mail list logo
