> > When I was working on HotSpot JVM, we had some problems with getcontext.
> > They work 99.99% of time. We added many workaround for the .01% cases. I
> > believe the Solaris guys have been improving the code. I am not sure of
> > the current status.
>
> Was that inside of a signal handler or
> > I used to be at Sun. I knew those warnings too. If we use longjmp
> > carefully, we can make it. In the worst case, write our own version.
>
> ..Or we could use setcontext/getcontext, could we not?
The setcontext/getcontext will be much worse than setjmp/longjmp.
The are more platform specif
> Actually I'd been given dire warnings from some of the Solaris folks.
> "Don't use setjmp with threads!"
>
> I've since gotten details, and it's "Don't use setjmp with threads
> and do Stupid Things."
I used to be at Sun. I knew those warnings too. If we use longjmp
carefully, we can make it.
> I've checked with some Sun folks. My understanding is that if you
> don't do a list of what I'd consider obviously stupid things like:
>
> *) longjmp out of the middle of an interrupt handler
> *) longjmp across a system call boundary (user->system->user and the
> inner jumps to the outer)
>
> >The thread-package-compatible setjmp/longjmp can be easily implemented
> >using assembly code. It does not require access to any private data
> >structures. Note that Microsoft Windows "Structured Exception Handler"
> >works well under thread and signal. The assembly code of __try will
> >show
> Okay, i've thought things over a bit. Here's what we're going to do
> to deal with infant mortality, exceptions, and suchlike things.
>
> Important given: We can *not* use setjmp/longjmp. Period. Not an
> option--not safe with threads. At this point, having considered the
> alternatives, I w
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
; 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:
> >
> >
> 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
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
> >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
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
> >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
> 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
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) /*
> 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
> 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
> 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
> 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
> 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
> 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 ...
> }
>
> ..
> 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()
> > 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
> 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'
and 'C'. The Uni
> > 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
> > 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
> (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
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:
> 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 -
> 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
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-
> 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
> 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
> 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
> 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
> > 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
> >
> >
> 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
> This patch moves integer constants to the constant table if the size
chosen
> for integers is not the same as the size chosen for opcodes.
It still leaves room for trouble. I suggestion we move everything that can
not be hold by int32_t out of opcode stream. The need for 64-bit constant
are rar
> Oh, they'll be able to have 64 (or 128, or 256) bit IVs. That's fine. It's
> just the in-stream integer constants that might be limited to 32 bits for
> portability reasons. Probably have to do some sort of odd:
>
>set I0, 0x12345678
>lshift I0, 32
>add I0, I0, 0x9ABCDEF0
I like
> On Sun, Sep 30, 2001 at 10:45:46AM -0700, Hong Zhang wrote:
> >Python uses global lock for multi-threading. It is reasonable for io
thread,
> >which blocks most of time. It will completely useless for CPU intensive
> >programs or large SMP machines.
>
> It migh
> Now how do you go about performing an atomic operation in MT? I
> understand the desire for reentrance via the exclusive use of local
> variables, but I'm not quite sure how you can enforce this when many
> operations are on shared data (manipulating elements of the
> interpreter / global varia
> > The memcpy() can handle alignment nicely.
>
> Not always. I tried. :(
How that could be possible? The memcpy() just does byte-by-byte
copy. It does not care anything about the alignment of source
or dest. How can it fail?
Hong
> This was failing here until I made the following change:
>
> PackFile_Constant_unpack_number(struct PackFile_Constant *
> self, char * packed, IV packed_size) {
> char * cursor;
> NV value;
> NV * aligned = mem_sys_allocate(sizeof(IV));
Are you sure this is correct? Or this
> >How does python handle MT?
>
> Honestly? Really, really badly, at least from a performance point of view.
> There's a single global lock and anything that might affect shared state
> anywhere grabs it.
Python uses global lock for multi-threading. It is reasonable for io thread,
which blocks mo
> > This is the wrong assumption. If you don't care about the call stack,
> > how can you expect the [sig]longjmp can successfully unwind stack?
> > The caller may have a malloc memory block,
>
> Irrelevant with a GC.
Are you serious? Do you mean I can not use malloc in my C code?
> > or have
> > This is fine at the target language level (e.g. perl6, python, jako,
> > whatever), but how do we throw catchable exceptions up through six or
> > eight levels of C code? AFAICS, this is more of why perl5 uses the
> > JMP_BUF stuff - so that XS and functions like sv_setsv() can
> > Perl_croak
> The fun part about async vs sync is there's no common decision on what's
an
> async signal and what's a sync signal. :( SIGPIPE, for example, is one of
> those. (Tru64, at least, treats it differently than Solaris)
>
> I generally divide signals into two groups:
>
> *) Messages from outsid
> In a word? Badly. :) Especially when threads were involved, though in some
> ways it was actually better since you were less likely to core perl.
>
> Threads and signals generally don't mix well, especially in any sort of
> cross-platform way. Linux, for example, deals with signals in thread
You are using the wrong flag. The expression in second is long long.
So you should use flag "%llx". Since printf uses vararg, it is
undefined behavior if there is type mismatch with argument.
Hong
> Hehehe. Ok. Guess what the following will print:
>
> #include
> int main(void) {
> int x
> > ># > 0xf000 for 64 bit systems. With that changed
>
> > Don't bother. Make the constant be ~0xfff. :)
>
> Umm, are you sure? It's used in an integer context and masked against an
> IV, so you might need an 'int', a 'long', or a 'long long'. I'm unsure
> what type to portably
> >Just curious, do we need a dedicated zero register and sink register?
>
> I've been pondering that one and waffling back and forth. At the moment I
> don't think so, since there's no benefit to going with a zero register
over
> a zero constant, but that could change tomorrow.
For example,
> Attached patch makes sure you don't try and use register numbers over
> 31. That is, this patch allows registers I0-I31 and anything else gets
> a: Error (foo.pasm:0): Register 32 out of range (should be
> 0-31) in 'set_i_ic'
>
> Oh, there's also a comment at end of line patch that has snuck i
> is it possible the ops to handle variable number of arguments, what I have
> in mind :
>
> print I1,",",N2,"\n"
This should be done by create array opcode plus print array opcode.
[1, 2, 3, 4, 5]
The create array opcode takes "n" top of stack (or "n" of registers)
and create an array out of
> you can't do non-blocking i/o on files without aio_read type calls. but
> what dan is saying is that the api the interpreter uses internally will
> be an async one. it will either use native/POSIX aio calls or simulate
> that with sync calls and callbacks or possibly with threads.
>
That sound
> Nope. Internal I/O, at least as the interpreter will see it is async. You
> can build sync from async, it's a big pain to build async from sync.
> Doesn't mean we actually get asynchrony, just that we can.
>
It is trivial to build async from sync, just using thread. Most Unix async
are built
> DS> I'm also seriously considering throwing *all* PerlIO code into
> separate
> DS> threads (one per file) as an aid to asynchrony.
>
> but that will be hard to support on systems without threads. i still
> have that internals async i/o idea floating in my numb skull. it is an
> api that
> One of the things that might be coring solaris is the potential for
> embedded floats in the bytecode stream. (The more I think about that the
> more I regret it...) The ops do a quick and ugly cast to treat some of the
> opcode stream as an NV which may trip across alignment rules and size
> Nope. There's *always* an integer type that works right. We won't be
> running on a platform that doesn't have 32-bit integers. (Well, not
without
> someone hacking the heck out of the core)
We should not rule out 16-bit system completely. It should be possible an
16-bit runtime can easily c
Do we want the opcode to be so complicated? I thought we are
going to use this kind of thing for generic pointers. The "p"
member of opcode does not make any sense to me.
Hong
> Earlier there was some discussion about changing typedef long IV
> to
> typedef union {
> IV i;
> void* p;
> } op
> Proposed: Parrot should never crash due to malformed bytecode. When
> choosing between execution speed and bytecode safety, safety should
> always win. Careful op design and possibly a validation pass before
> execution will hopefully keep the speed penalty to a minimum.
We can use similar mo
> Don't sweat system malloc behaviour all that much at the moment. We are
> going to be completely taking over memory allocation internally at some
> point reasonably soon, so as long as what you do doesn't crash we should
be
> fine. (It's OK to leak at this point--either the GC system or the
> There's a one-off conversion penalty at bytecode load time, and I don't
> consider that excessive. I want the bytecode to potentially be in platform
> native format (4/8 byte ints, big or little endian) with a simple and
> well-defined set of conversion semantics. That way the bytecode loader
> We can't do that. There are platforms on both ends that
> have _no_ native 32-bit data formats (Crays, some 16-bit
> CPUs?). They still need to be able to load and generate
> bytecode without ridiculuous CPU penalties (your Palm III
> is not running on a 700MHz Pentium III, after all!)
If the p
> 8-byte word:endianness (magic value 0x123456789abcdef0)
> byte: word size
> byte[7]:empty
> word: major version
> word: minor version
>
> Where all word values are as big as the word size says they are.
>
> The magic value can be something else, but it
> OffsetLength Description
> 0 1 Magic Cookie (0x013155a1)
> 1 n Data
> n+1 m Directory Table
> m+n+1 1 Offset of beginning of directory table (i.e. n+1)
I think we need a version right after cookie for long term compatibility.
> The directory is after
> I'd have thought it made sense to define it as a bytecode_t type, or
> some such which could be platform specific.
It is better called opcode_t, since we are not using bytecode anyway.
Hong
> If we are going to keep on doing fancy stuff with pointer arithmetic (eg
> the Alloc_Aligned/CHUNK_BASE stuff), I think we're also going to need an
> integer type which is guaranteed to be the same width as a pointer, so
> we can freely typecast between the two.
You are not supposed to do fancy
I think we should use int32_t instead of IV for all code related
data. The IV is 64-bit on 64-bit machine, which is significant
waste. The IV is also platform specific, and has caused some
nasty problems so far.
Hong
> Now works on Solaris and i386, but segfaults at the GRAB_IV call in
> read_constants_table on my Alpha. Problems with the integer-pointer
> conversions in memory.c? (line 29 is giving me a warning).
The line 29 is extremely wrong. It assigns IV to void* without casting.
The alignment calculatio
> At 09:15 PM 9/10/2001 +0100, Simon Cozens wrote:
> >FWIW, it's just dawned on me that if we want all of these things to be
> >overloadable by PMCs, they need to have vtable entries. The PMC vtable
> >is going to be considerably bigger than we anticipated.
>
> Who the heck is going to override a
> Uri Guttman
> > we are planning automatic over/underflow to bigfloat. so there is no
> > need for traps. they could be provided at the time of the
> > conversion to big*.
>
> OK. But will Perl support signaling and non-signaling NANs?
I don't think we should go for automatic overflow/underf
> At 06:26 PM 9/9/2001 -0700, Wizard wrote:
> >into something using a processor op equivalent to the 8051C
> >testbit( byte_variable, bit_offset).
>
> This is pretty much
>
>testbit I0, 6
>
> to test whether bit 6 is set i I0, right?
What is the difference from
and I0, I0, (1 << 6)
> If you really want a comparison, here's one. Take this loop:
>
> i = 0;
> while (i < 1000) {
>i = i + 7;
> }
>
> with the ops executed in the loop marked with pipes. The corresponding
> parrot code would be:
>
> getaddr P0, i
> store P0, 0
>
> True, but it is easier to generate FAST code for a register machine.
> A stack machine forces a lot of book-keeping either run-time inc/dec of
sp,
> or alternatively compile-time what-is-offset-now stuff. The latter is a
real
> pain if you are trying to issue multiple instructions at once.
I
I believe the advantage of
> if (...) {
> ...
> } else {
> ...
> }
is to write very dense code, especially when the block itself is single
line.
This style may not be readable to some people.
This style is not very consistent,
> if (...) {
> ...
> }
> else
> {
> ...
> }
I believe it w
> >If we define caller-save and callee save. The 64 register may
> >not be bad, as long as caller-save set is small.
>
> At least a full push without a copy to the new frame is dead
> cheap, so it's not much of a cost.
May not be true. If we use gc, we have to clear (nullify) it,
so the gc won
> >The branch instruction is wrong. It should be "branch #num".
> >The offset should be part of instruction, not from register.
>
> Nope, because that kills the potential for computed relative
> branches. (It's in there on purpose) Branches should work from
> both constants and registers.
Eve
There are many typos. Please correct them.
The branch instruction is wrong. It should be "branch #num".
The offset should be part of instruction, not from register.
The register set seems too big. It reduces cache efficiency
and uses too much stack. We also have to define caller saved
register
Actually we can use "call-setup-gp" calling convention to avoid patch.
It works like this:
1) each bytecode contains data section and code section.
2) during load, the runtime construct the data segment from the
data section, such as string object from string data, floating
point object fr
> >> Taiwanese read traditional chinese characters, but PRC people read
> > >> simplied chinese. Even we take the same data, and same program
(code),
> > >> people just read differently. As an end user, I want to make the
decision.
> > >> It will drive me crazy if Perl render/display the text fil
> The one problem with copy-on-write is that, if we implement it in
software,
> we end up paying the price to check it on every string write. (No free
> depending on the hardware, alas)
>
> Not that this should shoot down the idea of COW strings, but it is a cost
> that needs considering. (I
This is the common approach of complicated text representation,
the implemetations I have seen includes IBM IText and SGI
rope. For "rope", each rope is represented by either of a simple
immutable string, a simple mutable string, a simple immutable
substring of another rope, or a binary node of
> >What do you mean by character size if it does not support variable
length?
>
> Well, if strings are to be treated relatively abstractly, and we still
want
> to poke around through the string buffer, we need to know how big a
> character is.
I agree on this. I think support variable length
> * Convert from and to UTF-32
> * lengths in bytes, characters, and possibly glyphs
> * character size (with the variable length ones reporting in negative
numbers)
What do you mean by character size if it does not support variable length?
> * get and set the locale (This might not be the spot
We should let external collator to handle all these fancy features.
People can always normalize/canonicalize/do-whatever-you-want
and send the result text/binary to regex. All the features we
argue about here can be easily done by a customized collator.
Do NOT expect the Perl regex be a linguist
> However, I don't think this actually affects your comments, except that
> I'd guess that the half digits mentioned by Hong don't have the same
> term "case" used with them that the letters of various alphabets do.
I am not sure if we mean the same thing. The regular ascii "0123456789"
are call
> > What happens if unicode supported uppercase and lowercase numbers?
>
> > [I had a dig about, and it doesn't seem to mention lowercase or
> > uppercase digits. Are they just a typography distinction,
> and hence not
> > enough to be worthy of codepoints?]
>
> Damned if I know; I didn't know
> If this is the case, how would a regex like "^[a-zA-Z]" work (or other,
more
> sensitive characters)? If just about anything can come between A and Z,
and
> letters that might be there in a particular locale aren't in another
locale,
> then how will regex engine make the distinction?
This synt
> > I can't really believe that this would be a problem, but if they're
> > integrated alphabets from different locales, will there be issues
> > with sorting (if we're not planning to use the locale)? Are there
> > instances where like characters were combined that will affect the
> > sort order
e computer, and
> information is lost.
This is a very common practice, nothing to surprise. As you can tell,
my name is "hong zhang", which already lost "chinese tone" and
"glyph". "hong" has 4 tones, each tone can be any of several
characters, each charac
> Courtesy of Slashdot,
> http://www.hastingsresearch.com/net/04-unicode-limitations.shtml
>
> I'm not sure if this is an issue for us or not, as we're generally
> language-neutral, and I don't see any technical issues with any of the
> UTF-* encodings having headroom problems.
I think the au
> On Tue, Jun 05, 2001 at 11:25:09AM +0100, Dave Mitchell wrote:
> > This is the bit that scares me about unifying perl ops and regex ops:
> > can we really unify them without taking a performance hit?
>
> Coupl'a things: firstly, we can make Perl 6 ops as lightweight as we like.
>
> Second, Rub
> While RISC style opcodes have a certain pleasant simplicity to them, the
> opcode overhead'll kill us. (If perl 5's anything to go by, and in this
> case I think it might be)
I don't understand what the opcode overhead you meant. It can not be worse
than stack based opcode.
> The size of the
> There's no reason why you can.t have a hybrid scheme. In fact I think
> it's a big win over a pure register-addressing scheme. Consider...
The hybrid scheme may be a win in some cases, but I am not sure if it
worth the complexity. I personally prefer a strict RISC style opcodes,
mainly load, s
> here is an idea. if we use a pure stack design but you can access the
> stack values with an index, then the index number can get large. so a
> fixed register set would allow us to limit the index to 8 bits. so the
> byte code could look something like this:
>
> 16 bit op (plenty o
> Register based. Untyped registers; I'm hoping that the vtable stuff can be
> sufficiently optimized that there'll be no major win in
> storing multiple copies of a PMC's data in different types knocking
around.
>
> For those yet to be convinced by the benefits of registers over stacks,
try
>
>IIRC, ISO C says you cannot have /^_[A-Z_][A-Za-z_0-9]*$/. That's reserved
>for the standard.
If you consider our prefix is "_Perl_" not just "_", we will be pretty safe.
There are just not many people follow the standard anyway :-)
Hong
> The only problem with that is it means we'll be potentially altering the
> data as it comes in, which leads back to the problem of input and output
> files not matching for simple filter programs. (Plus it means we spend CPU
> cycles altering data that we might not actually need to)
>
I don't t
> > >We need the character equivalence construct, such as [[=a=]], which
> > >matches "a", "A ACUTE".
> >
> > Yeah, we really need a big list of these. PDD anyone?
> >
>
> But surely this is a locale issue, and not an encoding one? Not every
> language recognizes the same character equivalences
1 - 100 of 133 matches
Mail list logo
