On Sun, 17 Oct 2004 22:07:11 -0500 (CDT), Michel Pelletier <[EMAIL PROTECTED]> wrote: > This is my first chance to take a look at it but > I'm sorry I've nto been able to run it because > I'm on a different machine. I did look at the > code though.
Thanks for the feedback. I don't have time to respond to everything right now, but I thought I'd at least send an initial reply. > good chance to analyze it. There ar some > differences, like I keep the stack in a > register, you keep yours in a global, and you > store your core words in an "operations" global, > and I use a Parrot lexical pad. I've renamed this global to "words" since the release. Naming it "operations" reflects my Forth naivety. > I have no idea if storng something in a register > is worse than a global. I have certainly had > problems with IMCC stomping my well known > registers with $P? temp vars. Lexical pads vs > keeping your own hash are probably equivalent, > but perhaps pads have some cross-language > benefit. I think using a global is probably the only way to get around the register stomping. I don't think there would be any cross-language benefit from using lexical pads. In other languages, yes, but since Forth is built around a stack, another language can't very well call a Forth subroutine. It makes more sense to eval something like "1 2 sub .". I'd be interested in knowing how store_global/find_global differ in terms of speed/implementation. The same goes for the lexical opcodes. Dan or Leo? > I propose you and I work together to make a > totally Forth-language agnostic Forth > micro-kernel. This kernel can be very > minimalistic, a stacik, a machine state hash, > and definitions for the words "code", "next", > "word", and "'" (tick) all having standard Forth > behavior, a simple dictionary and a simple eval > loop. I'll reply to this portion of your email later, when I get time to think and to look at the Parakeet code. > Some Parakeet ideas might also be used in your > code, for example, it looks to me like your code > does direct threading: ... > Direct threading is a common Forth > implementation technique, but it was most often > used because it could be implemented portably in > C with only a small bit of asm. For smaller ops > like @ !, math ops, amd many others, it is more > optimal to use direct code generation to > "inline" the PIR code itself instead of > inlineing an invoke to the PIR code compiled as > as sub. ... > resulting in a lot less overhead for core words. > NCG was usually either a commercial feature or > rarely seen in Forth because it was > non-portable, being written in ASM, and > expensive to maintain and multiple platforms. > We can kick that problem to the door. I'm not sure that's right. I did think about putting the code inline (and it would be a trivial change to do so), but I'm not convinced it would be faster. Yes, you wouldn't have to deal with the overhead involved with making subroutine calls, but IMCC would also have to re-parse and re-compile the code every time. I really ought to benchmark it (later, when there's more time, I guess), but I wouldn't be surprised if calling the subroutines was faster. I can also investigate using the fastcall pragma since there are no parameters. Of course, I would need to add in the cost of doing a hash lookup as well, so you may be right. Ultimately, I don't care about speed so much for Forth. Maybe I should. I don't really plan on using it, so this is more of an exercise than anything else. It's more important to me that the implementation be clean and readable than for it to be fast. I want there to be a low learning curve. -- matt
