Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #1113

Re: Forth to Python Bytecode

Show all headers | View raw

BruceMcF <agila61@netscape.net> wrote:
> On Apr 9, 4:31?am, Andrew Haley <andre...@littlepinkcloud.invalid>
> wrote:
>> John Passaniti <john.passan...@gmail.com> wrote:
>> > On Apr 8, 6:19?pm, Brad <hwfw...@gmail.com> wrote:
>> >> What do you think of the feasibility of a Forth
>> >> compiler that generates Python bytecode? It seems
>> >> that native code sometimes conflicts with virus
>> >> checkers and/or the newest OS. Bytecode (.pyc)
>> >> runs on a bunch of platforms. It's stack-oriented,
>> >> but the return stack would have to be emulated.
>>
>> > I haven't looked at the Python VM in years and remember little about
>> > the instruction set and virtual architecture. ?But I would expect
>> > that the Python VM (like every other dynamic language VM I'm aware
>> > of) has no way to directly address memory. ?Memory in dynamic
>> > languages is managed for you, so pointers to memory are typically
>> > replaced with index variables. ?If you wanted to implement a
>> > traditional Forth, you would likely have to emulate RAM as a big
>> > array of bytes.
>>
>> As an alternative, in Java you could use a ByteBuffer, which has
>> methods for put and get all the data types. Unfortunately,
>> ByteBuffers use int as the index type, so you'd be limited to 4 Gbytes.
>> The big pain would be emulating the stack, though.
> 
> What is it about Java that argues against using the dictionary as a
> ByteBuffer and the stack as an int array? It seems like in C:
>    { data[i+1]=data[i+1]+data[i]; i++;}
> ... is fairly straightforward (stack growing down) ~ is it the global
> static data stack data[] and index i?

Nothing, I think that's a perfectly reasonable way to do it.  I don't
think hte stack would be global static: it would need to be at least
thread-local.  You'd have a Forth VM class with the stacks, the user
variables, and so on.

One problem with using an integer array for the stack is that the
optimizer has no way to know that items outside the stack are "don't
care".  As a trivial example, something like  DUP +  has no effect on
anything other than the top stack item, but the VM has no way to know
that and will dutifully make sure that region of the array outside the
stack is updated.  You can partly solve this sort of problem with a
peephole optimizer but that starts to get messy.

Andrew.

Back to comp.lang.forth | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Forth to Python Bytecode Brad <hwfwguy@gmail.com> - 2011-04-08 15:19 -0700
  Re: Forth to Python Bytecode John Passaniti <john.passaniti@gmail.com> - 2011-04-08 16:09 -0700
    Re: Forth to Python Bytecode Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-09 03:31 -0500
      Re: Forth to Python Bytecode BruceMcF <agila61@netscape.net> - 2011-04-09 13:13 -0700
        Re: Forth to Python Bytecode Andrew Haley <andrew29@littlepinkcloud.invalid> - 2011-04-10 03:21 -0500
  Re: Forth to Python Bytecode anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2011-04-09 13:39 +0000
  Re: Forth to Python Bytecode "The Beez'" <hansoft@bigfoot.com> - 2011-04-10 03:21 -0700

csiph-web