Just out of interest, what are the tests looking like on IRIX?
mmm...not so good.
- SWM
world:~/src/Perl/parrotuname -a
IRIX64 world 6.2 03131016 IP19
world:~/src/Perl/parrotmake test
perl t/harness
t/op/basic..ok 1/2skip() is UNIMPLEMENTED! at
/home/abhaile/swmcd/perl/lib/s
-opcode_t *(*(*opcode_funcs)[2048])(); /* Opcode */
- /* function table */
-STRING_FUNCS *(*(*string_funcs)[64])(); /* String function table */
+opcode_t *(**opcode_funcs)(); /* Opcode function table */
+STRING_FUNCS
IRIX64 6.2 cc -n32 issues 123 warnings (one per op code) complaining
that
interpreter.c, line 219: warning(1048): cast between pointer-to-object and
pointer-to-function
BUILD_TABLE(foo);
^
This patch makes them go away.
- SWM
Index: build_interp_starter.pl
RFC 178 proposes a shared data model for Perl6 threads. In a shared
data model
- globals are shared unless localized
- file-scoped lexicals are shared unless the thread recompiles the
file
- block scoped lexicals may be shared by
- passing a reference to them
- closures
- declaring one
SWM If you actually compile a Perl program, like
SWM $a = $b
SWM and then look at the op tree, you won't find the symbol "$b", or "b"
SWM anywhere in it. The fetch() op does not have the name of the variable
SWM $b; rather, it holds a pointer to the value for $b.
Where did you
You aren't being clear here.
fetch($a) fetch($a)
fetch($b) ...
add ...
store($a) store($a)
Now all of the perl internals are done 'safely' but the result is garbage.
You don't even
Example
@a = ();
async { push @a, (1, 2, 3) };
push @a, (4, 5, 6);
print @a;
Possible output: 142536
Actually, I'm not sure I understand this.
Can someone show how to program push() on a stack machine?
- SWM
I think there may be a necessity for more than just a work area to be
non-shared. There has been no meaningful discussion so far related to
the fact that the vast majority of perl6 modules will *NOT* be threaded,
but that people will want to use them in threaded programs. That is a
DS Some things we can guarantee to be atomic.
This is going to be tricky. A list of atomic guarentees by perl will be
needed.
From RFC 178
...we have to decide which operations are [atomic]. As a starting
point, we can take all the operators documented in Cperlop.pod and
all the functions
what if i do $i++ and overflow into the float (or bigint) domain? that
is enough work that you would need to have a lock around the ++. so then
all ++ would have implied locks and their baggage. i say no atomic ops
in perl.
From RFC 178
[Atomic] operations typically lock their operands
SWM Question: Can the interpreter determine when a variable becomes
SWM shared?
SWM Answer: No. Then neglecting to put a :shared attribute on a shared
SWM variable will crash the interpreter. This doesn't seem very Perlish.
Err, no. It won't crash the interpreter. It'll make the script
What I'm trying to do in RFC178 is take the thread model that you get
in compiled languages like C and C++, and combine it with the Perl5
programming model in a way that makes sense.
There may be reasons not to follow RFC178 in Perl6. Maybe
- it's too hard to implement
- there are performance
Single thingee access mediation, should be done automatically by perl.
The multi-thingee complex mediation should have the user step in, since
solving it (correctly and efficiently) is a complex problem.
I'm not sure we have a common understanding of the terms we are using.
Can you give some
I think we are talking about the same issues, but we can't seem to get
in sync on the terminology. I'm going to try to get off the
merry-go-round by recapitualting the two approaches.
RFC178
- globals are shared unless localized
- file-scoped lexicals are shared by all code in the file
-
14 matches
Mail list logo
