> > Okay, here's the updated scheme.
> >
> > *) There is a platform/generic.c and platform/generic.h. (OK, it'll
> > probably really be unixy, but these days it's close enough) If there is
no
> > pltform-specific file, this is the one that gets copied to platform.c
and
> > platform.h
> >
> >
> Also, note that Hong Zhang ([EMAIL PROTECTED]) has pointed out a
> simplification (1 API call rather than 2)...
FYI. The GetSystemTimeAsFileTime() takes less than 10 assembly instructions.
It just reads the kernel time variable that maps into every address space.
> and given I t
> void gettimeofday(struct timeval* pTv, void *pDummy);
> {
> SYSTEMTIME sysTime;
> FILETIME fileTime;/* 100ns == 1 */
> LARGE_INTEGER i;
>
> GetSystemTime(&sysTime);
> SystemTimeToFileTime(&sysTime, &fileTime);
> /* Documented as the way to get a 64 bit from a FIL
> Are there any cases where a void * cannot be placed into an integer
> register? It seems like it shouldn't happen, especially since jump and
> jsr are supposed to take an integer register and they point to a
> host-machine-address...
What register are you talking about? The 16-bit x86 has 16-b
> On Tue, 20 Nov 2001, Ken Fox wrote:
> > It sounds like you want portable byte code. Is that a goal?
> I do indeed want portable packfiles, and I thought that was more then a
> "goal", I thought that was a "requirement". In an ideal world, I want a
> PVM to be intergrated in a webbrowser the sam
> What we really need is our own s(n?)printf:
>
> Parrot_sprintf(target, "%I + %F - %I", foo, bar, baz);
> /* or some such nonsense */
> or even:
> target=Parrot_sprintf("%I + %F - %I); /* like Perl's built-in */
>
> That way, it could even handle Parrot strings nativel
I am not sure why we need the U postfix in the first place. For literal
like ~0xFFF, the compiler should automatically sign-extends to our
expected size. Personally, I prefer to using ([u]intptr_t) ~0xFFF,
which is more portable. So we don't have to deal with U, UL, i64.
It is possible to use 32-
> Also, the UL[L] should probably be on the inside of the ():
>
> stacklow => '(~0xfffULL)',
I still don't see this one is safer than my proposal.
~((uintptr_t) 0xfff);
Anyway, we should use some kind of macro for this purpose.
#ifndef foo
#define foo(a) ((uintptr_t) (a))
#endif
> That's what I thought I remembered; in that case, here's a patch:
>
> Index: core.ops
> ===
> RCS file: /home/perlcvs/parrot/core.ops,v
> retrieving revision 1.68
> diff -u -r1.68 core.ops
> --- core.ops 4 Jan 2002 02:36:25 -
By the way, we should not have global variable names like "index"
at the first place. All globals should look something like "GIndex".
Hong
> -Original Message-
> From: Simon Glover [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, January 08, 2002 9:56 AM
> To: [EMAIL PROTECTED]
> Subject:
> (1) There are 5.125 bytes in Unicode, not four.
> (2) I think the above would suffer from the same problem as one common
> suggestion, two-level bitmaps (though I think the above would suffer
> less, being of finer granularity): the problem is that a lot of
> space is wasted, since t
> > preprocessing. Another example, if I want to search for /resume/e,
> > (equivalent matching), the regex engine can normalize the case, fully
> > decompose input string, strip off any combining character, and do 8-bit
>
> Hmmm. The above sounds complicated not quite what I had in mind
> for
> > My proposal is we should use mix method. The Unicode standard class,
> > such as \p{IsLu}, can be handled by a standard splitbin table. Please
> > see Java java.lang.Character or Python unicodedata_db.h. I did
> > measurement on it, to handle all unicode category, simple casing,
> > and decim
> But e` and e are different letters man. And re`sume` and resume are
> different words come to that. If the user wants something that'll
> match 'em both then the pattern should surely be:
>
>/r[ee`]sum[ee`]/
I disagree. The difference between 'e' and 'e`' is similar to 'c'
and 'C'. The Uni
> Yes, that's somewhat problematic. Making up "a byte CEF" would be
> Wrong, though, because there is, by definition, no CCS to map, and
> we would be dangerously close to conflating in CES, too...
> ACR-CCS-CEF-CES. Read the character model. Understand the character
> model. Embrace the chara
> > But e` and e are different letters man. And re`sume` and resume are
> > different words come to that. If the user wants something that'll
> > match 'em both then the pattern should surely be:
> >
> >/r[ee`]sum[ee`]/
>
> I disagree. The difference between 'e' and 'e`' is similar to 'c
> Should we be allowed to use _ to group numbers, now that _ is concat?
> If not _, then what? (if anything?)
Sure. In Perl 5, we have 123.456 and a . b, but in Perl 6, we will have
123_456 and 123 _ 456. People have to put space around '_' anway.
Hong
> I believe the main difficulty comes from heading into uncharted waters.
For
> example, once you've decided to make garbage collection optional, what
does
> the following line of code mean?
>
> delete x;
If the above code is compiled to Parrot, it probably equivalent to
x->~Destructor()
> This changes the way a programmer writes code. A C++ class
> and function that uses the class looks like this:
>
> class A
> {
> public:
> A(){...grab some resources...}
> ~A(){...release the resources...}
> }
>
> void f()
> {
> A a;
> ... use a's resources ...
> }
>
> ..
> Because parts of an rx can be case-insensitive while other parts
> are case-sensitive, we will probably need two sorts of ops anyway
> (or a way to tell the op to be case-insensitive). And you will
> only be able to do the case folding when the whole rx is
> case-insensitive.
I don't like you
> But as you say, case folding is expensive. And with this approach you
> are going to case-fold every string that is matched against an rx
> that has some part of it that is case-insensitive.
That is correct in general. But regex compiler can be smarter than that.
For example, rx should optimize
> Agh, if you go and do that, you must then be sure that rx is capable of
> optimizing /a/i and /[aA]/ in the same way. What I mean is that Perl's
> current regex engine is able to use /abc/i as a "constant" in a string,
> while it cannot do the same for /[Aa][Bb][Cc]/. Why? Because in the
> fi
> mops tests :
>
> on perl5,python I get - 2.38 M/ops
> ruby ~ 1.9 M/ops
> ps ~ 1.5 M/ops
>
> parrot - 20.8 M/s
> parrot jitted - 341 M/ops and it finish in half second ... for most of
> the other I have to wait more that a minute ..
Frankly speaking, this number is misleading. I know the pytho
> The following patch adds a Parrot_nosegfault() function
> to win32.c; after it is called, a segmentation fault will print
> "This process received a segmentation violation exception"
> instead of popping up a dialog. I think it might be useful
> for tinderbox clients.
Please notice, stdio is no
If the function is intended to be inlined, why we need prototype for it.
The INLINE function should have immediate implementation, and not prototype.
I will use the following macro to handle this.
#if defined(__GNUC__) /* && __GNUC__ > nnn */
# define INLINE __inline__
#elif defined(_MSC_VER) /*
> Would it be good to say exactly what type of rounding this is? What
> is 19 / 5? How about 19 / -5? FWIW, here's what Perl
> currently thinks:
>
> 19 / 5 = 3
> (-19)/ 5 = -3
> 19 /-5 = -3
> (-19)/-5 = 3
On way to solve this is to provide two sets of division operators, ie
div/mod vs
> >That's (potentially) an awfully big table. But maybe I'm missing the
point.
> >If we're not trusting the bytecode to be safe, and this table is part of
the
> >bytecode, how do we know the table is safe?
>
> We vet the table at load time to make sure it's safe. That way we
> avoid the cost of
I have been concerned with the current parrot design for some time.
I don't see the clear direction for parrot.
If a vm is designed for JIT, it can be very simple on opcode system.
To real compilers, there is no difference between opcodes and regular
function calls. The compiler can inline the
> >The KVM of Java includes pre-verify info, which serves similar purpose.
The
> >reason behind is Java bytecode verification is (kind of) NP-complete. By
> >using pre-verify info, the problem can be reduced to linear in most case.
(No one
> >prove it mathmatically, but you got the idea.)
>
> Hmm
Can you check what is the sizeof(INTVAL) and sizeof(void*)?
Some warnings should not have happened.
Hong
> -Original Message-
> From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 16, 2002 10:24 AM
> To: [EMAIL PROTECTED]
> Subject: 64 bit Debian Linux/PowerPC OK
> 1) NO STATIC VARIABLES! EVER!
> 2) Don't hold on to pointers to memory across calls to routines that
> might call the GC.
> 3) Don't hold on to pointers to allocated PMCs that aren't accessible
> from the root set
I don't think the rule #2 and #3 can be achieved without systematic
effort. In
; From: Michael G Schwern [mailto:[EMAIL PROTECTED]]
> Sent: Saturday, March 16, 2002 2:54 PM
> To: Hong Zhang
> Cc: [EMAIL PROTECTED]
> Subject: Re: 64 bit Debian Linux/PowerPC OK but very noisy
>
>
> On Sat, Mar 16, 2002 at 02:36:45PM -0800, Hong Zhang wrote:
> >
> >
I think it will be relative easy to deal with different compiler
and different operating system. However, ICU does contain some
C++ code. It will make life much harder, since current Parrot
only assume ANSI C (even a subset of it).
Hong
> This is rather concerning to me. As I understand it, on
101 - 133 of 133 matches
Mail list logo
