"AT" == Adam Turoff [EMAIL PROTECTED] writes:
AT On Tue, Oct 24, 2000 at 10:55:29AM -0400, Chaim Frenkel wrote:
I don't see it.
I would find it extremely akward to allow
thread 1:*foo = \one_foo;
thread 2:*foo = \other_foo;
[...]
copy the foo body to a new location.
"BS" == Benjamin Stuhl [EMAIL PROTECTED] writes:
BS 1. Bytecode can just be mmap'ed or read in, no playing
BS around with relocations on loading or games with RVAs
BS (which can't be used anyway, since variable RVAs vary based
BS on what's been allocated or freed earlier).
(What is an RVA?)
On Wed, Oct 25, 2000 at 11:45:54AM -0400, Chaim Frenkel wrote:
I vaguly can see a TIL that uses machine code linkage (real machine code
jumps) that perhaps could use relative addressing as not needing
relocation. But I'm not sure that all architectures support long enough
relative
Dan Sugalski wrote:
Numeric constants will probably fall into two classes--those perl's parser
knows about and can convert to, and those it doesn't and just treats as
strings.
I'm really excited to see what magic Larry is going to cook up for
extending the lexer and parser. His talk made it
At 12:48 PM 10/25/00 -0400, Ken Fox wrote:
If Larry does what I'm hoping, we'll be able to extend the lexer to
recognize new number formats and not have to kludge things together with
strings. Am I reading too much into the Atlanta talk or is that your
take on it too?
I think you're likely
David Mitchell wrote:
Well, I was assuming that there would be *a* numeric class in scope
- as defined be the innermost lexical 'use foo'.
And that numeric class would remove int and num from the scope?
I assumed that Perl wouldn't be clever enough to know about all available
numberic types
--- Chaim Frenkel [EMAIL PROTECTED] wrote:
"BS" == Benjamin Stuhl [EMAIL PROTECTED] writes:
BS 1. Bytecode can just be mmap'ed or read in, no
playing
BS around with relocations on loading or games with RVAs
BS (which can't be used anyway, since variable RVAs vary
based
BS on what's been
Adam Turoff wrote:
when dealing with threaded bytecode is that the threading specifically
eliminates the indirection in the name of speed.
Yes. Chaim was saying that for the functions that need indirection,
they could use stubs. You don't need to guess in advance which ones
need indirection
In message [EMAIL PROTECTED]
Nicholas Clark [EMAIL PROTECTED] wrote:
Specific example where you can't:
on ARM, the branch instructions (B and BL) are PC relative, but only have
a 24 bit offset field. The address space is (now) 32 bit, so there's parts
you can't reach without either
On Wed, Oct 25, 2000 at 06:23:20PM +0100, Tom Hughes wrote:
In message [EMAIL PROTECTED]
Nicholas Clark [EMAIL PROTECTED] wrote:
Specific example where you can't:
on ARM, the branch instructions (B and BL) are PC relative, but only have
a 24 bit offset field. The address space
Joshua N Pritikin writes:
: http://www.oreillynet.com/pub/a/python/2000/10/04/stackless-intro.html
Perl 5 is already stackless in that sense, though we never implemented
continuations. The main impetus for going stackless was to make it
possible to implement a Forth-style treaded
"KF" == Ken Fox [EMAIL PROTECTED] writes:
KF Adam Turoff wrote:
when dealing with threaded bytecode is that the threading specifically
eliminates the indirection in the name of speed.
KF Yes. Chaim was saying that for the functions that need indirection,
KF they could use stubs. You don't
12 matches
Mail list logo
