Random questions...
David
I've lightly gone through the documentation Perl Assembly Language
documentation a couple times, and I'm confused over a couple of (hopefully
simple) points. Keep in mind that I'm not a Perl coder:
1. How do you handle variant (either string or numeric) data? Do you set up
one of the string registers with a string "ssnnnnssnnnn" to keep track of
datatypes?
2. What happens if a routine needs more than 32 variables of one datatype? Do
you use hash tables? (Sounds like Lua)
3. What about variant arrays? Hash tables again?
4. What's a frame? (ex: push_p : Push the current frame of the PMC...)
5. How are pointers from DLLs handled? For example, I might have a DLL routine
which returns a pointer of some flavor, or expects pointers as parameters. Is
there a 'void *' PMC?
6. What's a "scratchpad?" Is it different from a "pad?" What are they used
for?
7. How are pad *descriptors* created? They are specified in the constant area
of the bytefile, but it's not clear how they get there. Then again, I'm not
entirely clear on what they are, either.
8. How do you store things in non-global pads? There is a store_global opcode,
but no store_lex opcode.
9. Is there a substring op? If not, how do you get a substring?
10. I didn't see any equality (eq, gt, le, etc.) opcodes for comparing values.
11. There's no opcode for supporting a for loop?
12. There's a string to number op, but no number to string op?
I've also got a couple questions related to the byetcode file format. These
are more idle curiosity:
1. Was there a compelling reason to mix the strings and numbers into the
constant section, instead of creating a seperate string and numeric section?
2. Are duplicate values (strings, numbers) consolidated in the data section?
3. Why store numbers in binary format instead of text format? Doesn't that
limit precision?
Thanks!
-- David Cuny
Leopold Toetsch
> 1. How do you handle variant (either string or numeric) data? Do you set up
> one of the string registers with a string "ssnnnnssnnnn" to keep track of
> datatypes?
N/Y. This would need probably a new PMC type.
> 2. What happens if a routine needs more than 32 variables of one datatype? Do
> you use hash tables? (Sounds like Lua)
imcc (the assembler) generates spill code, using a PerlArray.
> 4. What's a frame? (ex: push_p : Push the current frame of the PMC...)
It's a register frame, used for subroutine calling. Current registers of
one type are copied to a save area and restored from there on sub return.
> 5. How are pointers from DLLs handled? For example, I might have a DLL routine
> which returns a pointer of some flavor, or expects pointers as parameters. Is
> there a 'void *' PMC?
These are return in UnmanagedStruct PMCs. s. nci.c
> 6. What's a "scratchpad?" Is it different from a "pad?" What are they used
> for?
They store the names/PMCs of lexical variables.
> 7. How are pad *descriptors* created? They are specified in the constant area
> of the bytefile, but it's not clear how they get there. Then again, I'm not
> entirely clear on what they are, either.
The variable names (as they are created) happen to be in the constant
table, because these are strings. Have a look at t/pmc/scratchpad.t for
usage.
> 8. How do you store things in non-global pads? There is a store_global opcode,
> but no store_lex opcode.
There is store_lex/find_lex.
> 9. Is there a substring op? If not, how do you get a substring?
3 variants of substr s. core.ops
> 10. I didn't see any equality (eq, gt, le, etc.) opcodes for comparing values.
Again, please consult core.ops, they have exactly above names.
> 11. There's no opcode for supporting a for loop?
No, only labels, branches and if/unless/eq/gt/...
> 12. There's a string to number op, but no number to string op?
ord, chr, sprintf
> 1. Was there a compelling reason to mix the strings and numbers into the
> constant section, instead of creating a seperate string and numeric section?
Dan would probably say "hysterical raisins". But 2 sections don't have
much advantage, and we have key constants too.
> 2. Are duplicate values (strings, numbers) consolidated in the data section?
They are folded, yes.
> 3. Why store numbers in binary format instead of text format? Doesn't that
> limit precision?
This is currently worked on. We probably might have a text format
sometimes. OTOH 8/12/16 byte doubles ought to have enough precision.
> Thanks!
Welcome
> -- David Cuny
leo
David
>> 1. How do you handle variant (either string or numeric) data? Do you set
>> up one of the string registers with a string "ssnnnnssnnnn" to keep track
>> of datatypes?
> N/Y. This would need probably a new PMC type.
OK. This is pretty common with a lot of scripting languages, so I was suprised
Parrot didn't handle it at a lower level.
> > 2. What happens if a routine needs more than 32 variables of one
> > datatype? Do you use hash tables? (Sounds like Lua)
>
> imcc (the assembler) generates spill code, using a PerlArray.
Ah, so that's what "spill code" means. Perhaps a definition of the term in the
document might be helpful.
> > 4. What's a frame? (ex: push_p : Push the current frame of the PMC...)
>
> It's a register frame, used for subroutine calling. Current registers of
> one type are copied to a save area and restored from there on sub return.
OK, thanks. I was guessing that it might be, but I wasn't sure it didn't have
to do with native calls as well.
> > 9. Is there a substring op? If not, how do you get a substring?
>
> 3 variants of substr s. core.ops
D'oh! I had forgotton that the ops were extensible, even though I had read
through them. I guess I expected those ops to be documented in the Assembly
Language document anyway.
> > 10. I didn't see any equality (eq, gt, le, etc.) opcodes for comparing
> > values.
>
> Again, please consult core.ops, they have exactly above names.
Urgh. For some reason, I expected them in the core docs also.
Thanks again!
-- David Cuny
Leopold Toetsch
> Leo wrote:
>>imcc (the assembler) generates spill code, using a PerlArray.
> Ah, so that's what "spill code" means. Perhaps a definition of the term in the
> document might be helpful.
$ grep spill docs/*.pod :)
leo
Dan Sugalski
>Wow, Parrot has certainly made a lot of progress since I've last looked at it.
I see Leo's answered a bunch of this already, but since I'm digging
through my mail, I'll do it as well.
>1. How do you handle variant (either string or numeric) data? Do you set up
>one of the string registers with a string "ssnnnnssnnnn" to keep track of
>datatypes?
? I'm not sure what you're talking about here. If you mean data
that's almost but not quite a builtin string/int/float, then you'd
use a custom PMC class. If that's not what you mean, then I'm not
sure.
>2. What happens if a routine needs more than 32 variables of one datatype? Do
>you use hash tables? (Sounds like Lua)
If you're passing it in (as a sub call) the overflow goes in a stack
segment. Inside routines things get pushed and popped onto the stack.
>3. What about variant arrays? Hash tables again?
? Probably with a custom PMC class.
>4. What's a frame? (ex: push_p : Push the current frame of the PMC...)
A register set--all the int, string, float, or PMC registers. Each
register set has a separate backing stack, and when you push a frame
you push all the registers of a particular type onto their backing
stack in one go.
>5. How are pointers from DLLs handled? For example, I might have a DLL routine
>which returns a pointer of some flavor, or expects pointers as parameters. Is
>there a 'void *' PMC?
Either unmanagedstruct or managedstruct objects. And if those aren't
enough, we can build another PMC class that works. (I expect we'll
have a PMC class that holds a struct pointer put can pull fields out
by name at some point)
>6. What's a "scratchpad?" Is it different from a "pad?" What are they used
>for?
Holding lexical variables for a scope.
>7. How are pad *descriptors* created? They are specified in the constant area
>of the bytefile, but it's not clear how they get there. Then again, I'm not
>entirely clear on what they are, either.
>
>8. How do you store things in non-global pads? There is a store_global opcode,
>but no store_lex opcode.
There is a store_lex opcode, amongst others. I see PDD06 desperately
needs updating. The docs are in core.ops, and if you have perl
installed you can use perldoc to extract and read it. (Or the other
pod tools, such as pod2html) It'd look like:
perldoc core.ops
>9. Is there a substring op? If not, how do you get a substring?
Yup--substr.
>10. I didn't see any equality (eq, gt, le, etc.) opcodes for comparing values.
They're in there too.
>11. There's no opcode for supporting a for loop?
Who's for, C's or perl's? C's for doesn't need an opcode. Perl's
arguably might, but I think we'll be better off putting the count of
things into an I register and iterating through the list as an array.
>12. There's a string to number op, but no number to string op?
Should be. If not, we should fix.
>I've also got a couple questions related to the byetcode file format. These
>are more idle curiosity:
>
>1. Was there a compelling reason to mix the strings and numbers into the
>constant section, instead of creating a seperate string and numeric section?
Well... Hysterical Raisins. That arguably should be fixed.
>2. Are duplicate values (strings, numbers) consolidated in the data section?
If they're not now, they should be.
>3. Why store numbers in binary format instead of text format? Doesn't that
>limit precision?
It avoids conversion loss. Besides, it's faster, and that's the point. :)
--
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
d...@sidhe.org have teddy bears and even
teddy bears get drunk
gre...@focusresearch.com
> Who's for, C's or perl's? C's for doesn't need an opcode. Perl's
> arguably might, but I think we'll be better off putting the count of
> things into an I register and iterating through the list as an array.
Four words: Lazy Lists.
Regards,
-- Gregor
Dan Sugalski
Well, arguably lazy lists ought to know how big they are, but I can
also see potentially just saying "Gimme element X" for values of X
ranging from 0 to the point where we give up.
Good point, though. Unfortunately. :(