cotto

Earlier today at YAPC::EU, jnthn mentioned a number of features and needs that
would be especially helpful to Rakudo.  I though I ought to relay those items.
They are as follows.

1) Threading - this isn't a pressing concern right now, but we'll need to
something about it in the near future.  nine, (a.k.a. Stefan Seifert) dropped
by #parrot and is apparently here at yapc.  I'll try to find him.  From what
I've heard he's interested in helping Rakudo's threading, which means whipping
Parrot's threading into shape.  In the event that he's interested, I'd like to
ask for a mentor to guide him through Parrot's guts and help him get working

cotto

It's become increasingly clear that a shift in the way we regard M0 is needed.  A minimalist instruction set can be made to work with an intelligent optimizer, but we're not going to have any such optimizer at least for the first several months and probably for much longer.  We can't build M0 with the assumption that it's going to be highly optimized because in the common case, it's not.  Building an M0 that's hard for humans to write directly is absolutely fine, but building one that can't be executed efficiently by a simple "raw" (non-optimizing) compiler/assembler/interpreter is unacceptable.  If rewriting Parrot's C code in Mole consistently produces inferior performance, we might as well dispand and recommend the JVM.  not_gerd is doing us a huge favor by pointing this out, though it means substantial redesigning M0 at a point when we were just getting ready for the final implementation.

Blargh.  That's all.  It's still better to do it right.  It'll take more time, but we'll end up with a workable produ

cotto

use strict;
use warnings;

use File::Spec;
use IO::Select;
use IPC::Open3;

# Starts HBDB and sets the debugee file and command-line arguments

# Don't write to `HBDB_STDIN` anymore when child has exited

cotto

perl -e 'print unpack("i", pack("i", -2315606021))."\n";'
x64: 1979361275
x86: -2147483648

perl -e 'print unpack("i", pack("i", -2315606022))."\n";'
x64: 1979361274
x86: -2147483648

What I need is something to chop off anything after 4 bytes.  Actually, that's a lie.  What I actually need is to know that the value will fit within the range of an int32.  

cotto

void main() {
    const char * str = "jellyfish";
    char ch;
    unsigned long int hash = 0;
    while (ch = *str++) {
        long int tmp = ch;
        //hash = ch + (hash << 6) + (hash << 16) - hash;

        printf("step 1: tmp = %ld\n", tmp);
        tmp = tmp + (hash << 6);

cotto

=head2 Libraries

* libmain chunk - returned when m0b is loaded as a library
* main chunk - executed when m0b is loaded initially
* load_m0b instruction:
  - load m0b from filename
  - read/parse m0b file
  - append chunks to INTERP
  - perform fixups (makes chunk name constants dtrt)
  - return index of libmain chunk

cotto

So, I wants me some function pointer-like thingies in M0.  They're simple to pass around, they're easy to understand for those coming from a C background, they store nicely and they're quick to invoke.  Everybody wins.

There are three aspects of function pointers: lookup, storage and invocation.  Storage is pretty simple; stuff the address into a register, bam.  Lookup and invocation are a bit more tricksy.  The address space is split up on a per-chunk basis.  Function pointers are a highly runtimey thing, so having them depend on the runtime state f the interpreter is just fine.  If function pointers only ever need to point at the beginnging of a chunk, the implementation is pretty simple.  A function pointer is just the number of the chunk it points at, and invoking is as simple as gotoing to it.  Introducing anything more fine-grained may make sense, but I'm loathe to do so without at least a theoretical use case.

That gives us two cases: chunk-based function pointers and instruction based function point

cotto

.version 0
.chunk "byte_ops_test"
.constants
0 "string thing?"
1 "\n"
.metadata
.bytecode

    # print byte value of first byte of string 0
    set_imm S0, 0, 0

cotto

So, we need some kind of profiling.  imcc is nearly worthless concerning line
numbers*, so that information is basically useless until we're on PIRATE or
someone rides in with shining armor and fixes imcc once and for all.  For the
time being, ignoring imcc's line numbers is the best way forward.  

That leaves us with sub-level profiling.  pmichaud has already done some work
here to great effect with a quick and dirty hack, so this more limited form of
profiling will still allow useful work to be done.

The question now shifts to what this sub-level profiler will look like.

cotto

Probably the biggest question is what language we want to use.  We'll be
spending a huge amount of time writing whatever it is.  We need some criteria:

 * how easy is the language to learn for people accustomed to C
 * does the language has an object system?  We'll be implementing cmop (6model)
   in it, so the object system needs to be either self-hosting or non-existent
 * how efficiently does the language map to M0?  We want to generate efficient
   M0 and to have a clear idea of what the M0 for a given snippet looks like
 * it shouldn't allow things that don't make sense in M0 (not sure what this means)
 * the language should allow CPS stuff, either directly or indirectly.