Re: strings: "sequence-of-integer ... list of chunks"
On Thu, 31 Jan 2002, Bryan C. Warnock wrote: > print "There's a letter in here!\n" if (substr($pi, 0, 200) =~ /[a-z]/); *shrug* I actually did think of that when I first proposed this; doesn't substr make a fresh copy of the string? (I honestly don't know.) What happens if you take a substring of a generator? Have you just "used up" the first 200 characters? What if I the thing I'm matching on is tied, and taking a substring of it has side effects? Plus the fact that, folding this functionality into the regex engine gives us an extra set of tools for doing optimizations with...if we can determine that their pattern cannot match more than N characters, then we can stop after N characters, without having to take substrs or such. I assume we're going to have this ability in the RE for its own use...why not make it directly available to the user? Dave
Idea: JIT support for pbc2c
Would it be good, bad, or indifferent to have pbc2c able to emit "asm" sections where appropriate? How difficult would it be? -- > I never thought I'd say this, but you're getting very strange. Thank God: I thought it was everybody else. - J-P Stacey
386 JIT broken
I'm sorry if this is a known bug. my.pasm ( useless, just a contrived example ): set I1, 12 FOO: if I1, FOO BAR: if I1, BAR if I1, FOO end assembly: 0x816bda8: push %ebp 0x816bda9: mov%esp,%ebp 0x816bdab: int3 0x816bdac: movl $0xc,0x815150c 0x816bdb6: mov%esi,%esi 0x816bdb8: mov0x815150c,%eax 0x816bdbd: cmp$0x0,%eax 0x816bdc0: jne0x816bdb7<== wrong 0x816bdc6: nop 0x816bdc7: mov0x815150c,%eax 0x816bdcc: cmp$0x0,%eax 0x816bdcf: jne0x816bdc6<== correct 0x816bdd5: nop 0x816bdd6: mov0x815150c,%eax 0x816bddb: cmp$0x0,%eax 0x816bdde: jne0x816bdb7 <== wrong 0x816bde4: nop 0x816bde5: leave 0x816bde6: ret If I move the "set I1, 12" after the foo label, both jumps are correct. Regards Mattia
Parrot FAQ
I have added Adam's Parrot FAQ to www.parrotcode.org. It's being loaded from cvs.perl.org every hour, so just checkin updates to cvs there. I do, $Faq =~ s!.*(.*).*!$1!s; $Faq =~ s!href="http://www.panix.com/~ziggy/parrot.html!href="/faq/!g; on it to "fix it up", so when changing stuff, keep that in mind (or tell me to fix the mason component). It also tells that Ziggy is the maintainer. Ziggy, please let me know if you don't want to be listed. :-) There are no 's in the html, so the links from the toc doesn't work. If anyone wants to fix that, please do. - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: Parrot FAQ
On Saturday 02 February 2002 08:53, Ask Bjoern Hansen wrote: > I have added Adam's Parrot FAQ to www.parrotcode.org. > > It's being loaded from cvs.perl.org every hour, so just checkin > updates to cvs there. > > I do, > > $Faq =~ s!.*(.*).*!$1!s; > $Faq =~ s!href="http://www.panix.com/~ziggy/parrot.html!href="/faq/!g; > > on it to "fix it up", so when changing stuff, keep that in mind (or > tell me to fix the mason component). It also tells that Ziggy is the > maintainer. Ziggy, please let me know if you don't want to be > listed. :-) > > There are no 's in the html, so the links from the toc > doesn't work. If anyone wants to fix that, please do. Thanks, Ask, Here's the name patch: Index: ParrotFAQ.htm === RCS file: /home/perlcvs/parrot/docs/ParrotFAQ.htm,v retrieving revision 1.1 diff -u -r1.1 ParrotFAQ.htm --- ParrotFAQ.htm 26 Jan 2002 00:37:38 - 1.1 +++ ParrotFAQ.htm 2 Feb 2002 14:40:17 - @@ -99,10 +99,10 @@ 7. http://www.panix.com/~ziggy/parrot.html#id308673";>Really? -1 General Questions +1 General Questions -1. What is Parrot? +1. What is Parrot? Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual @@ -111,7 +111,7 @@ bytecode-compiled languages such as Python, Ruby and Tcl. -2. Why "Parrot"? +2. Why "Parrot"? The name "Parrot" relates to Simon Cozen's http://www.perl.com/pub/a/2001/04/01/parrot.htm"; target=_top>April Fool's @@ -121,7 +121,7 @@ of time as Parrot's lead developer. -3. Is Parrot the same thing as Perl6? +3. Is Parrot the same thing as Perl6? No. Parrot is an implementation that is expected to be used to execute Perl6 programs. The Perl6 language definition is currently (December 2001) being @@ -132,7 +132,7 @@ -4. Can I use Parrot today? +4. Can I use Parrot today? Well, almost. :-) Parrot is in the early phases of its implementation. The primary way to use @@ -147,7 +147,7 @@ -5. Why should I program in Parrot Assembly language? +5. Why should I program in Parrot Assembly language? Lots of reasons, actually. :-) @@ -166,8 +166,8 @@ -6. When can I expect to use Parrot with a real programming language? +6. When can I expect to use Parrot with a real programming language? It depends on what you mean by real. :-) @@ -186,24 +186,24 @@ -7. What language is Parrot written in? +7. What language is Parrot written in? C -8. For the love of god, man, why?!?!?!? +8. For the love of god, man, why?!?!?!? Because it's the best we've got. -9. That's sad. +9. That's sad. So true. Regardless, C's available pretty much everywhere. Perl 5's in C, so we can potentially build any place perl 5 builds. -10. Why not write it in insert favorite -language here +10. Why not write it in insert favorite +language here Because of one of: @@ -217,8 +217,8 @@ -11. Why your own virtual machine? Why not compile to JVM/.NET? - +11. Why your own virtual machine? Why not compile to JVM/.NET? + Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. @@ -226,16 +226,16 @@ an interpreter geared towards dynamic languages. -12. So you won't run on the JVM/.NET? +12. So you won't run on the JVM/.NET? Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends. -2 Parrot and Perl +2 Parrot and Perl -1. Why reimplement Perl? +1. Why reimplement Perl? Good question. At The Perl Conference 4.0, in the summer of 2000, Larry Wall -2. You want to write the Perl compiler in Perl? +2. You want to write the Perl compiler in Perl? Sure. Why not? C, Java, Lisp, Scheme and practically every other language is self-hosting. Why not? -3. Isn't there a bootstrapping problem? +3. Isn't there a bootstrapping problem? No, not really. Don't forget we can use Perl5 to run Perl5 programs, such as a Perl5 to Parrot compiler. -4. How will Parrot handle both Perl5 and Perl6? +4. How will Parrot handle both Perl5 and Perl6? We don't know yet, since it depends on the Perl6 language definition. But we could use the more appropriate of two @@ -291,49 +291,49 @@ -5. Is this how Parrot will run Python, Ruby and Tcl code? +5. Is this how Parrot will run Python, Ruby and Tcl code? Probably. -6. Latin and Klingon too? +6. Latin and Klingon too? No, Parrot won't be twisted enough for Damian. Perhaps when Parrot is ported to a pair of supercooled Calcium ions, though... -7. Huh? +7. Huh? You had to http://www.csse.monash.edu.au/~damian/papers/#Superpositions"; target=_top>be there. -3 Parrot Implement
Re: Parrot FAQ
On Saturday 02 February 2002 09:37, Bryan C. Warnock wrote: Disregard previous. I forgot to turn off word wrap. Index: ParrotFAQ.htm === RCS file: /home/perlcvs/parrot/docs/ParrotFAQ.htm,v retrieving revision 1.1 diff -u -r1.1 ParrotFAQ.htm --- ParrotFAQ.htm 26 Jan 2002 00:37:38 - 1.1 +++ ParrotFAQ.htm 2 Feb 2002 14:40:17 - @@ -99,10 +99,10 @@ 7. http://www.panix.com/~ziggy/parrot.html#id308673";>Really? -1 General Questions +1 General Questions -1. What is Parrot? +1. What is Parrot? Parrot is the new interpreter being designed from scratch to support the upcoming Perl6 language. It is being designed as a standalone virtual @@ -111,7 +111,7 @@ bytecode-compiled languages such as Python, Ruby and Tcl. -2. Why "Parrot"? +2. Why "Parrot"? The name "Parrot" relates to Simon Cozen's http://www.perl.com/pub/a/2001/04/01/parrot.htm"; target=_top>April Fool's @@ -121,7 +121,7 @@ of time as Parrot's lead developer. -3. Is Parrot the same thing as Perl6? +3. Is Parrot the same thing as Perl6? No. Parrot is an implementation that is expected to be used to execute Perl6 programs. The Perl6 language definition is currently (December 2001) being @@ -132,7 +132,7 @@ -4. Can I use Parrot today? +4. Can I use Parrot today? Well, almost. :-) Parrot is in the early phases of its implementation. The primary way to use @@ -147,7 +147,7 @@ -5. Why should I program in Parrot Assembly language? +5. Why should I program in Parrot Assembly language? + Lots of reasons, actually. :-) @@ -166,8 +166,8 @@ -6. When can I expect to use Parrot with a real programming language? +6. When can I expect to use Parrot with a real programming language? It depends on what you mean by real. :-) @@ -186,24 +186,24 @@ -7. What language is Parrot written in? +7. What language is Parrot written in? C -8. For the love of god, man, why?!?!?!? +8. For the love of god, man, why?!?!?!? Because it's the best we've got. -9. That's sad. +9. That's sad. So true. Regardless, C's available pretty much everywhere. Perl 5's in C, so we can potentially build any place perl 5 builds. -10. Why not write it in insert favorite -language here +10. Why not write it in insert +favorite +language here Because of one of: @@ -217,8 +217,8 @@ -11. Why your own virtual machine? Why not compile to JVM/.NET? - +11. Why your own virtual machine? Why not compile to +JVM/.NET? + Those VMs are designed for statically typed languages. That's fine, since Java, C#, and lots of other languages are statically typed. Perl isn't. @@ -226,16 +226,16 @@ an interpreter geared towards dynamic languages. -12. So you won't run on the JVM/.NET? +12. So you won't run on the JVM/.NET? Sure we will. They're just not our first target. We build our own interpreter/VM, then when that's working we start in on the JVM and/or .NET back ends. -2 Parrot and Perl +2 Parrot and Perl -1. Why reimplement Perl? +1. Why reimplement Perl? Good question. At The Perl Conference 4.0, in the summer of 2000, Larry Wall -2. You want to write the Perl compiler in Perl? +2. You want to write the Perl compiler in Perl? + Sure. Why not? C, Java, Lisp, Scheme and practically every other language is self-hosting. Why not? -3. Isn't there a bootstrapping problem? +3. Isn't there a bootstrapping problem? No, not really. Don't forget we can use Perl5 to run Perl5 programs, such as a Perl5 to Parrot compiler. -4. How will Parrot handle both Perl5 and Perl6? +4. How will Parrot handle both Perl5 and Perl6? + We don't know yet, since it depends on the Perl6 language definition. But we could use the more appropriate of two @@ -291,49 +291,49 @@ -5. Is this how Parrot will run Python, Ruby and Tcl code? +5. Is this how Parrot will run Python, Ruby and Tcl +code? Probably. -6. Latin and Klingon too? +6. Latin and Klingon too? No, Parrot won't be twisted enough for Damian. Perhaps when Parrot is ported to a pair of supercooled Calcium ions, though... -7. Huh? +7. Huh? You had to http://www.csse.monash.edu.au/~damian/papers/#Superpositions"; target=_top>be there. -3 Parrot Implementation issues +3 Parrot Implementation issues -1. What's with this whole register machine thing? +1. What's with this whole register machine thing? + Not much, why do you ask? -2. Don't you know that stack machines are the way to go in software? - +2. Don't you know that stack machines are the way to go +in software? + No, in fact, I don't. -3. But look at all the successful stack-based VMs! +3. But look at all the successful stack-based VMs! + Like what? There's just the JVM. -4. What about all the others? +4. What about all the others? *What* other
RE: parrot rx engine
On Jan 31, Hong Zhang said: >> 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 /a+/i to /[aA]+/ to avoid case-folding. >If it is too difficult for rx to do case-folding, I think it is better >to use some normalizer to do full-case folding. 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 first case, the string being matched against has been folded, so "abc" will or will not be in the string. In the second case, the string has not been folded, so scanning for that "constant" string would require either a) temporary folding to look for "abc" b1) looking for "a" or "A" and then... b2) looking for "b" or "B" and then... b3) looking for "c" or "C" That sounds like more effort that it's worth. Perl's current engine handles /abc/i much faster than /[Aa][Bb][Cc]/. -- japhy, the perl hacker with one red shoe
Re: Parrot FAQ
On Sat, 2 Feb 2002, Bryan C. Warnock wrote: > On Saturday 02 February 2002 08:53, Ask Bjoern Hansen wrote: > > I have added Adam's Parrot FAQ to www.parrotcode.org. > > > > It's being loaded from cvs.perl.org every hour, so just checkin > > updates to cvs there. > > > > I do, > > > > $Faq =~ s!.*(.*).*!$1!s; > > $Faq =~ s!href="http://www.panix.com/~ziggy/parrot.html!href="/faq/!g; > > > > on it to "fix it up", so when changing stuff, keep that in mind (or > > tell me to fix the mason component). It also tells that Ziggy is the > > maintainer. Ziggy, please let me know if you don't want to be > > listed. :-) > > > > There are no 's in the html, so the links from the toc > > doesn't work. If anyone wants to fix that, please do. > > Thanks, Ask, > > Here's the name patch: Cool. I applied it. Next time please apply yourself or send it without messed up line endings. :) - ask -- ask bjoern hansen, http://ask.netcetera.dk/ !try; do();
Re: ARM JIT (just about)
On Fri, 1 Feb 2002, Nicholas Clark wrote:
> On Fri, Feb 01, 2002 at 01:32:13AM +, Nicholas Clark wrote:
> > This just about implements a jit for ARM. It doesn't actually do any ops in
> > assembler yet, except for end. It's names on the basis that it's for v3 or
>
> This is where I give up on the current format.
> Others are welcome to carry on either based on what I did, or starting
> afresh. And we have a fresh format I'm interested.
> What I've written will call parrot ops.
>
> > Problems that I remember that I encountered. (Comments in the code may
> > indicate more). Part of these were understanding things - it doesn't mean
> > that the current way is wrong, just that it wasn't obvious to me :-(
> >
> > 1: '}' is a necessary character in ARM assembler syntax, so jit2h.pl needs
> >to be a bit smarter about deciding when to chop the end of a function
> >
> > 2: There is no terse way to load arbitrary 32 bit constants into a register
> >with ARM instructions. There are 2 usual methods
> >1: Put the constant in a constant pool within +- 4092 or so bytes of the
> > PC, and load it with an offset from the PC.
We should probably go this way.
> >2: Make it with 1, 2 or 3 instructions. I believe that currently it is
> > conjectured that it is possible to make any 32 bit value with 3 ARM
> > instructions, and so far no-one has found any value that they couldn't
> > make, but no-one has proved it possible and thereby made an algorithm
> > that lets a program generate instructions to build a constant
> >
> >Either way, I found I was fighting the current jit which expects (at worst)
> >to be able to split a 32 bit constant into 2 (possibly unequal) halves
> >stored in two machine instructions. To be more flexible jit would need to
Wrong, that's not possible on the ALPHA, or may be it is (don't know much
about ALPHA assembly) but I don't use it.
I think the main problem with ARM is that you don't have intructions like
the alpha "ldah" or the sparc "sethi" which do something like:
"ldah $1,2($2)"
$1 = (2 * 65536 + $2)
That why we should use a constant pool.
> >know what some CPU registers contain (ie things like the current
> >interpreter pointer), and be able to choose whether to get a value or
> >pointer by arithmetic from a CPU register, by deferencing a CPU register
> >(possibly with offset) or by giving up and loading a constant
> >
> >This will make more sense to anyone who gets hold of an ARM machine and
> >then tries to write ops :-)
> >
> > 3: I wanted to put the pointer to the current interpreter in r7. This made
> >the default precompiled "call" function have its branch somewhere wonky.
> >It seems to me that Parrot::Jit->call should be returning a 2 item list
> >the bytecode, and the offset of the branching instruction in there.
>
> Actually, I'd like to do arbitrary call like this:
>
> mov r1, r7; say arg 2 is *interpreter
> adr r14, .L1 ; pseudocode for pc relative calc.
> ldmia r14!, {r0, r2, r3, pc} ; register list built by jit
> ..L1:r0 data
> r2 data
> r3 data
> ; address of function.
> ..L2: ; next instruction - return point from func.
>
> Which to me doesn't look much like the way the current system expects to
> prime the registers in order.
>
> ARM SPECIFIC BIT:
>
> I'm taking advantage of the way that a branch to subroutine instruction
> (bl) stores the return address in r14 (lr, the Link register), and loads
> pc (r15) with the subroutine address.
> The above (untested) code takes advantage of r14 (and r15) being regular
> registers, by replacing all the load registers with function parameters,
> call function into 1 (yay!) instruction which (effectively) treats r14 as a
> stack pointer.
>
> 1 instruction to prime r14 with the address of label .L1 (1 clock cycle)
> 1 instruction to:
>
> loads all the registers with parameters
> load the program counter with the subroutine address (so branch into it)
> write back new pointer value to r14 (which will be pointing at .L2)
>which has effectively set the return address for the function.
>
> admittedly that load takes >1 clock cycle. But it just seems a cool way to do
> it.
>
>
> LESS ARM SPECIFIC BIT:
>
> However, building the ldmia instruction means setting the bitmap of registers
> to load based on which are values in the hitlist between .L1 and .L2. And if
> some are already in CPU registers, or are actually to be loaded from Parrot
> registers, then they don't need to be pulled from the hitlist, because they
> are being evaluated some other way.
> (eg I think it is a good idea to keep the current interpreter pointer in a
> CPU register (eg r7), hence if that is needed as a function parameter it's
> a mov, rather than a memory load)
>
> And if arguments need deferencing first, then I need to load th
Re: Idea: JIT support for pbc2c
Well I thought about generating executables directly, still didn't even thought about how, but it's on my TODOSOMEDAY list. Daniel Grunblatt. On Sat, 2 Feb 2002, Simon Cozens wrote: > Would it be good, bad, or indifferent to have pbc2c able to emit > "asm" sections where appropriate? How difficult would it be? > > -- > > I never thought I'd say this, but you're getting very strange. > Thank God: I thought it was everybody else. > - J-P Stacey >
Re: 386 JIT broken
Yes, it's a known bug, the problem is with the output of objdump. We need to write a tool to assemble. Daniel Grunblatt. On Sat, 2 Feb 2002, Mattia Barbon wrote: > I'm sorry if this is a known bug. > my.pasm ( useless, just a contrived example ): > set I1, 12 > FOO: > if I1, FOO > BAR: > if I1, BAR > if I1, FOO > end > > assembly: > 0x816bda8: push %ebp > 0x816bda9: mov%esp,%ebp > 0x816bdab: int3 > 0x816bdac: movl $0xc,0x815150c > 0x816bdb6: mov%esi,%esi > 0x816bdb8: mov0x815150c,%eax > 0x816bdbd: cmp$0x0,%eax > 0x816bdc0: jne0x816bdb7<== wrong > 0x816bdc6: nop > 0x816bdc7: mov0x815150c,%eax > 0x816bdcc: cmp$0x0,%eax > 0x816bdcf: jne0x816bdc6<== correct > 0x816bdd5: nop > 0x816bdd6: mov0x815150c,%eax > 0x816bddb: cmp$0x0,%eax > 0x816bdde: jne0x816bdb7 <== wrong > 0x816bde4: nop > 0x816bde5: leave > 0x816bde6: ret > > If I move the "set I1, 12" after the foo label, > both jumps are correct. > > Regards > Mattia >
how to JIT ?
hi, how to compile JITed code ... !! Is there some list of tweaks, switches that can be used to speed up the Parrot? Particulary for people like me that are not very close to C programming :") thanx alot raptor [EMAIL PROTECTED]
Re: how to JIT ?
On 2 Feb 2002, raptor wrote: > hi, > > how to compile JITed code ... !! Just add the -k switch when you invoke test_parrot. > Is there some list of tweaks, switches that can be used to speed up the > Parrot? Particulary for people like me that are not very close to C > programming :") That's the big one. -P speeds things up too, though not as much. Generally speaking things are pretty raw, but that's OK, as we're stuill pre-alpha. We'll get better, and odds are the -j switch will be on by default on those platforms that support it, and the -P switch in places that don't. Dan
Re: how to JIT ?
On Sat, 2 Feb 2002, Dan Sugalski wrote: > On 2 Feb 2002, raptor wrote: > > > hi, > > > > how to compile JITed code ... !! > > Just add the -k switch when you invoke test_parrot. Argh. Typo. Invoke the JIT with -j. Dan
Re: ARM JIT (just about)
On Sat, Feb 02, 2002 at 05:40:30PM -0300, Daniel Grunblatt wrote: > > On Fri, 1 Feb 2002, Nicholas Clark wrote: > > > On Fri, Feb 01, 2002 at 01:32:13AM +, Nicholas Clark wrote: > > >Either way, I found I was fighting the current jit which expects (at worst) > > >to be able to split a 32 bit constant into 2 (possibly unequal) halves > > >stored in two machine instructions. To be more flexible jit would need to > > Wrong, that's not possible on the ALPHA, or may be it is (don't know much > about ALPHA assembly) but I don't use it. Ooops. Sorry. I couldn't guess much of what the alpha was up to. I felt I had a better grasp of what the sparc assembler was doing. > I think the main problem with ARM is that you don't have intructions like > the alpha "ldah" or the sparc "sethi" which do something like: What does ldah do? [Hey, what does sethi do for that matter? :-)] Oh. You've just said: > "ldah $1,2($2)" > > $1 = (2 * 65536 + $2) > > That why we should use a constant pool. Was sethi the one I thought that could put some of a 32 bit constant in a register. So that in combination with another opcode one could load all 32 bits of a register. And if ldah is not loading the bottom 17 bits of the register, does that mean that there's another alpha opcode to load (at least) 17 bits of a register? If so, yes, that's the problem. There is no ARM opcode, well no pair of ARM opcodes, to load a 32 bit value into a register. You either have to build the 32 bit value from one or more arithmetic ops, or arrange to have the 32 value in a data word somewhere "nearby" to do a PC relative memory load. > > CONCLUSION: > > > > So I start needing to build simple, parameterisable code, but more complex > > than the current system allows. > > The current system handles object code at build_asm time, if understand > what you mean, you need it to handle assembler? Sorry, I think I didn't explain clearly. Probably because it's not totally clear in my head. I'm quite happy to write C code that generates or mangles the correct ARM instructions. It's more that I felt it was getting too tricky to try and specify the parameterisable bits of the assembly code by using special syntax in core.ops, which the perl code has to recognise as special syntax, substitute in legal assembler syntax, assemble the substitute code, disassemble it, remember where the special syntax was, and then note for build_asm where something was. I was also getting quite confused trying to remember what all the numbers were in jit2h.pl. (Well, I know that they are offsets into the entries in the C struct, but there weren't enough symbolic names to jog my memory. Also, it was starting to feel like it was getting rather "special cased" for everything. I wanted some clear way to define in core.ops: load r1 with the value of int reg N or load r2 with the address of the interpreter and not have to worry about whether I was getting that via a register load, or arithmetic from some other register (this was particularly acute in the "call a function" code. It might be a good idea to make a special function to make JIT code for "call a parrot opcode", as this could be more specialised, and hence more efficient, than the general "call some C function") I also wanted to be able to define somewhere (in one place, not 3): Addresses of int reg N are found by offsetting from CPU register 4 and for build_asm be able to define pairs of things, such as: this relocation is "mangle an LDR instruction" the value is "address of int reg N - address of int reg 0" or this relocation is "mangle a B instruction" the value is CPU pc - address of function "foo" > > 1: reads that > > 2: mangles &INT_REG[1] to something that is syntactically legal > > 3: calls out to as > > 4: calls objdump to disassemble it > > 5: looks for a pattern to spot where the special bit is. > >AARGH. The "special bit" is the last 12 bits of the instruction. > >If I have to convert the disassembled instruction back to binary, and > >then match /^010...(.)$/ to find out if it's > >LDR or STR (with $1 determining which) I feel I might as well write my > >own ARM assembler in perl > No, you can leave everything as it is in this stage and then over write > the necesary bits at build_asm time. > > Anyway steps 3 to 4/5 may disappear as we should write our own assembler > because of the objdump problems. Ah right. OK. Writing an ARM assembler should be relatively easy, for the subset of ARM instructions used the majority of the time. I may even be able to "phone a friend" and find one pre-written. [er. then someone is going to want the floating point assembler.] > > 7: I need to teach jit.c that on this architecture it is doing INT_REG > >loads in this way. (There is a forest of #ifdef rapidly growing there, as > >it seems every architecture is not as "simple" as x86) > There are some ways to get rid of the #ifdef forest, bu
[pythonesque] vtable ideas
Hi all- I have been checking the Python source code (something I am sure all of you already have done :-) and some differences on the design surprised me so much that I decided to come and make some questions. I guess that most of you know well the python source code, so please apologize the lengthy mail. I focused on reviewing the implementation of PythonObjects (Python's PMC) and found some interesting points that I would like to discuss with this list. These are: I. Missing methods in parrot: The are many vtable methods in python not present in parrot. Some of the ones I would expect to really be needed are: * divmod# integer division * power * absolute * invert * compare And probably many others.¿Is there any reason not to have this ones at least? They've got also a bunch of methods for things like calling builtin methods, getting and setting object attributes, and so on. But I guess these ones should better stay out until that part of the design is more advanced. BTW, ¿do we have any idea of how will user-defined objects look like? ¿Will methods be object's attributes, or just a funny syntax to call functions? ¿Will Parrot allow user-defined class to inherit from builtin-classes (another Python's requirement)? II. The "protocols" concept In Parrot, there is a single vtable structure for objects. Python, in the other hand, defines a set of protocols that are optionally implemented by objects (Number, Sequence, Mapping, Buffer and Iterator I think). Objects that implement the Number protocol have a non null entry on the main vtable called tp_as_number that holds a pointer to yet another vtable with the number-relatad methods. This allow for easy checking if an object can be operated numerically (just test pmc->vtable->as_number != NULL) but adds yet an indirection level (pmc->vtable->add gets pmc->vtable->as_number->add) I cannot tell what other design or performance benefits produces the choice of putting so frequently used methods in a deeper indirection level but would love to listen from those who know more. III. A different solution for coercion In Parrot, we currently define a new family of methods for each type of number (or string btw). So we have: void add (PMC * value, PMC* dest) void add_int (INTVAL value, PMC* dest) void add_bigint (BIGINT value, PMC* dest) void add_float (FLOATVAL value, PMC* dest) void add_bigfloat (BIGFLOAT value, PMC* dest) void add_same (PMC * value, PMC* dest) If we wanted to a add a new number or string type (for instance a Complex type), then we should create a new family of add_complex, subtract_complex, etc.. methods, and implement them on each PMC class. Intuition tells that this cannot be the best way to handle this problem. Python's solution is to define an intermediate function (let's call it Perl_NumberAdd) that implements the coercions between numbers, so the PMC is only responsible of implementing the "add" method with an object of the same type (what is currently add_same) This simplifies very much the creation of hierarchy of types for numbers, and localizes the changes to make when a new number type is introduced. Additionally, in the specific Parrot case (where we want to execute code of different programming languages) I would say that this is the only way to do the right thing, because the same mathematical operation can require different coercion polices for different languages. (Think on perl, who automatically converts strings to numbers when performing an "add", against python, who would raise a type error). So it looks to me that coercion doesn't belong to the object domain, but to the language domain, (since a number born in perl could easily end up in python) and thus its code shouldn't live in the vtable but in the opcode (or a function called by it), and that we should have two different opcodes for python's add (py_add), and perl's add (perl_add). To sum up: kill all the exotic versions of add, subtract and friends, and implement coercion in a per-language function, that gets called by a per-language opcode version. -- I am honestly not very sure to make much sense in any of these, and I am more than willing to learn why our way is better than their's, if that's the case. On the other hand... who knows. If any of this pythonesque influences haves some interest for Parrot, (I am particulary interested in the third one) I would volunteer to contribute a patch attempt for it. Angel Faus [EMAIL PROTECTED]
Re: [pythonesque] vtable ideas
On Sun, 3 Feb 2002, Angel Faus wrote: > I. Missing methods in parrot: > > The are many vtable methods in python not present in parrot. Some of the > ones I would expect to really be needed are: > >* divmod# integer division >* power >* absolute >* invert >* compare Yes, we are short a few vtable methods. We probably want one for everything that we can currently overload in perl5 (albeit from perl space). > They've got also a bunch of methods for things like calling builtin methods, > getting and setting object attributes, and so on. But I guess these ones > should better stay out until that part of the design is more advanced. I imagine these will translate down to simple subroutine calls in parrot or calls to specialised C code that implements them. > III. A different solution for coercion > > In Parrot, we currently define a new family of methods for each type of > number (or string btw). So we have: > > void add (PMC * value, PMC* dest) > void add_int (INTVAL value, PMC* dest) > void add_bigint (BIGINT value, PMC* dest) > void add_float (FLOATVAL value, PMC* dest) > void add_bigfloat (BIGFLOAT value, PMC* dest) > void add_same (PMC * value, PMC* dest) > If we wanted to a add a new number or string type (for instance a Complex > type), then we should create a new family of add_complex, subtract_complex, > etc.. methods, and implement them on each PMC class. These methods are provided so that we can play with "native" types in our bytecode then send them to our pmc, as otherwise every constant in our code would have to be a PMC, which is a little excessive. Things like a complex number will be represented by either a PMC class (very likely for complex numbers) or a language level overloaded class (like a Quantum::Entanglement). > Additionally, in the specific Parrot case (where we want to execute code of > different programming languages) I would say that this is the only way to do > the right thing, because the same mathematical operation can require > different coercion polices for different languages. (Think on perl, who Thus we have PerlInts, PythonInts etc... In general these will inherit from default.pmc except where they do something different. > So it looks to me that coercion doesn't belong to the object domain, but to > the language domain, (since a number born in perl could easily end up in > python) and thus its code shouldn't live in the vtable but in the opcode (or Passing things between languages will need a well defined type coercion mechanism. In general I expect that a PerlString will be turned into a string constant then loaded into a PythonString by code that knows what it's doing. After all, we need to do something simillar when passing SVs into C code at the moment, and I'm sure Inline::* will provide not only endless amusement but also some useful advice on this. Alex Gough -- It is easier -- even quicker, once you have the habit -- to say "In my opinion it is not an unjustifiable assumption that" than to say "I think".
