Forth and the Perl 6 virtual machine, Parrot 
Author Message
 Forth and the Perl 6 virtual machine, Parrot

A while back I found out about the plan to do the next version of Perl using
a virtual machine to be written in C, from a resource site (I think it was
http://www.*-*-*.com/ ). The Perl people are implementing Perl 6 in parallel
with its virtual machine, and to test that out they had an assembler and
various simple/little languages on it, like Basic. Naturally I asked whether
Forth was on the agenda. Nobody replied then, but now I hear that someone has
been and gone and implemented a Forth in Parrot - not as a practical
proposition, but to exercise the virtual machine properly.

Another thing I wondered was, why just implement Parrot in C? Whereas that
does make it sort of portable, there are a lot of portability tricks people
invented for Forth, so why not apply them? It might be worth some Forther's
while to adapt the scheme behind eforth to make an "eparrot", a generic
version in skeleton assembler that could easily be transferred even if it was
not as optimal as convenient. Or the ideas behind metacompiling could be
adapted, so a Perl 6/Parrot implementation running a specialised generator
could generate a binary image for a new architecture/platform. Or (gasp)
Parrot could even be implemented directly in Forth (which allows recursively
nested emulation), though Parrot's own architecture isn't a good match for a
stack machine.

Oh, I'm quite busy and I don't have enough familiarity with Parrot's
internals to jump in myself just yet. PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://www.*-*-*.com/ ~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Sat, 02 Apr 2005 21:20:22 GMT  
 Forth and the Perl 6 virtual machine, Parrot


Quote:
> The Perl people are implementing Perl 6 in parallel
> with its virtual machine, and to test that out they had
> an assembler and various simple/little languages on it,
> like Basic. Naturally I asked whether Forth was on
> the agenda. Nobody replied then, but now I hear that
> someone has been and gone and implemented a Forth
> in Parrot - not as a practical proposition, but to
> exercise the virtual machine properly.

I fearlessly predict that after the dust settles on Parrot, you are going to
find plenty of people implementing a variety of languages on top of that
virtual machine.  It's just a matter of history.  Whenever people have come
out with a popular and compelling virtual machine, others have always ported
their favorite languages to it.  Back in the days of the UCSD p-System,
there were a number of languages available that rode on top of that, not
just Pascal.  And today with Sun's JVM and Microsoft's CLR, you see the same
thing.  Python has been ported to the JVM, Perl is now able to generate .NET
code, and so on.

Because Parrot isn't specific to Perl, you may find other languages
eventually use Parrot as the underlying virtual machine.

Quote:
> Another thing I wondered was, why just implement
> Parrot in C? Whereas that does make it sort of
> portable, there are a lot of portability tricks people
> invented for Forth, so why not apply them?

For at least two reasons I can think of:

First, aside from quality free ANSI C compilers being available for
virtually every processor on the planet, there is a significant body of
experience in creating C code that is both efficient and portable.  The same
can't be said for Forth.  As the old joke used to go, "If you've seen one
Forth, you've seen, well, one Forth."  Portability wasn't even a serious
issue for Forth users until ANS Forth came along.  Parrot is written in C
because the authors wanted to reach the highest number of platforms.  If and
when ANS Forth ever gets to that level, then it might be a contender for
portable systems-level programming.  But not yet.

But more importantly, portability just isn't a big deal in the Forth
culture.  Look for example at the comments by Charles Moore at
http://www.colorforth.com/binding.html to see his views on portability.
These views are often reflected here in comp.lang.forth and in other Forth
forums.  Portability just isn't a strong element of Forth culture-- at least
not now.  ANS Forth is helping to change that, which is helping to splinter
Forth into the usual arbitrary divisions.

Quote:
> It might be worth some Forther's
> while to adapt the scheme behind eforth to make an
> "eparrot", a generic version in skeleton assembler that
> could easily be transferred even if it was not as optimal
> as convenient. Or the ideas behind metacompiling could
> be adapted, so a Perl 6/Parrot implementation running a
> specialised generator could generate a binary image for
> a new architecture/platform. Or (gasp) Parrot could even
> be implemented directly in Forth (which allows recursively
> nested emulation), though Parrot's own architecture isn't
> a good match for a stack machine.

In short, all of the wide variety of clever and interesting things people
have done with other virtual machines are going to be able to be done with
Parrot.  Look also for JIT compilers, tools to do automated testing,
profilers, "hot spot" optimizers, etc.


Mon, 04 Apr 2005 04:12:02 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:

>Another thing I wondered was, why just implement Parrot in C? Whereas that
>does make it sort of portable, there are a lot of portability tricks people
>invented for Forth, so why not apply them?

They do, they are implementing it in C:-).

Quote:
> It might be worth some Forther's
>while to adapt the scheme behind eforth to make an "eparrot", a generic
>version in skeleton assembler that could easily be transferred even if it was
>not as optimal as convenient.

What's the point?  It makes porting the stuff to new platforms
significantly more work than just saying "./configure; make" (OTOH,
installing Perl has always been a lot of work; maybe they are waiting
until autoconf is written in Perl before they do anything about it).

And what would be the point?

- Speed?  Looking at
<http://www.complang.tuwien.ac.at/forth/performance.html>, Gforth
outperformed plain eforth, so no, speed would not be the point
(although I don't think that the standard Parrot implementation will
outperform either eforth or Gforth on such benchmarks).

- Portability to machines without C?  On such machines a lot of the
library calls that Perl uses are not available, so Perl does not make
much sense there.

But of course, since it's a spec, you can try and do an eparrot
yourself, and see which implementation wins (in speed, portability, or
popularity).

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Thu, 07 Apr 2005 18:56:26 GMT  
 Forth and the Perl 6 virtual machine, Parrot
Quote:



.
.

Quote:
> > It might be worth some Forther's
> >while to adapt the scheme behind eforth to make an "eparrot", a generic
> >version in skeleton assembler that could easily be transferred even if it was
> >not as optimal as convenient.

> What's the point?  It makes porting the stuff to new platforms
> significantly more work than just saying "./configure; make"

For a start, THAT's not portable.

 (OTOH,

Quote:
> installing Perl has always been a lot of work; maybe they are waiting
> until autoconf is written in Perl before they do anything about it).

> And what would be the point?

> - Speed?

No, I already admitted that the optimality wasn't the objective. It would
have to be a trade off thing, so one could pull it out of the repertoire on
those occasions when it was justified - and only then. I do expect that a lot
of extra effort could make the beast efficient - but then, that sort of
effort could port C. So it doesn't feature as a point in the trade off space.

Quote:

> - Portability to machines without C?  On such machines a lot of the
> library calls that Perl uses are not available, so Perl does not make
> much sense there.

Ah, but that was rather the point; how much of the functionality could be
implemented in a non-C based way? I rather suspect that you could only do it
with the help of a lot of the tricks that have been worked out down the years
- which points towards eforth as one possibility. The hard work would come in
all the reverse engineering, but at least that would be cleaner than some of
the reverse engineering that happens these days. Not to mention ethical.

Quote:

> But of course, since it's a spec, you can try and do an eparrot
> yourself, and see which implementation wins (in speed, portability, or
> popularity).

I considered that, but there are two serious problems at this point:-

- my own lack of time and other resources (which is why I threw it out in
case it engaged anyone else's interest); and

- the specification doesn't look precisely stable just yet, though I plan on
asking a Perl Mongers' visiting speaker about that soon (there may be enough
to get started with).

If nothing else, done the right way projects like this can turn things up
that can be used in other contexts. I wasn't expecting any great achievement.
PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Fri, 08 Apr 2005 21:55:00 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:



>.
>.
>> > It might be worth some Forther's
>> >while to adapt the scheme behind eforth to make an "eparrot", a generic
>> >version in skeleton assembler that could easily be transferred even if it was
>> >not as optimal as convenient.

>> What's the point?  It makes porting the stuff to new platforms
>> significantly more work than just saying "./configure; make"

>For a start, THAT's not portable.

Please elaborate.  What do you mean with "portable"?

For me portability has two aspects:

1) The number and variety of platforms on which the software runs.

2) The effort that it takes to make it run on another platform.

The most portable large pieces of software I know work with
"./configure; make" (with a configure that finds out by itself what it
needs, unlike Perl).

Quote:
>> - Portability to machines without C?  On such machines a lot of the
>> library calls that Perl uses are not available, so Perl does not make
>> much sense there.

>Ah, but that was rather the point; how much of the functionality could be
>implemented in a non-C based way?

The problem here is not C, but the general environment.  If a platform
nowadays has no C, it also has no file system.  So you can forget
about all the functionality for dealing with file systems and a good
part of the Perl programs out there.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Thu, 14 Apr 2005 18:26:41 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:




> >.
> >.
> >> > It might be worth some Forther's
> >> >while to adapt the scheme behind eforth to make an "eparrot", a generic
> >> >version in skeleton assembler that could easily be transferred even if it was
> >> >not as optimal as convenient.

> >> What's the point?  It makes porting the stuff to new platforms
> >> significantly more work than just saying "./configure; make"

> >For a start, THAT's not portable.

> Please elaborate.  What do you mean with "portable"?

> For me portability has two aspects:

> 1) The number and variety of platforms on which the software runs.

> 2) The effort that it takes to make it run on another platform.

> The most portable large pieces of software I know work with
> "./configure; make" (with a configure that finds out by itself what it
> needs, unlike Perl).

I go for number 2, but for that very reason - and based on past experiences -
I do NOT consider you can start with the functionality that you are assuming
is present. Rhetorically, what is "./configure; make"? Something that works
within an environment - and that you might not have. Sure, it almost
certainly exists for a platform - but YOU might not have it. My own
experiences were from an environment that I recommended C for, only to be
told "you will use assembler because we already know about that".
Politically, all you can count on is whatever comes bundled, not on what
exists somewhere else and COULD be run if only you had it. (I cheated by
rolling my own Forth, so as to have at least some sort of high level language
despite being forbidden to use the right tool for the job.)

I am doing some work in Perl on a Windows platform at the moment. Political
reasons have deprived me of hardware resources. I don't think I would have
been allowed C if I had asked.

Quote:

> >> - Portability to machines without C?  On such machines a lot of the
> >> library calls that Perl uses are not available, so Perl does not make
> >> much sense there.

> >Ah, but that was rather the point; how much of the functionality could be
> >implemented in a non-C based way?

> The problem here is not C, but the general environment.  If a platform
> nowadays has no C, it also has no file system.

I beg to differ. See above - SOMEONE has C, including people who use the very
same platform you have, but the platform in front of you might not.

  So you can forget

Quote:
> about all the functionality for dealing with file systems and a good
> part of the Perl programs out there.

Where I am coming from is something where I might have the very minimal
bundled stuff, and access to data via peripherals; that "data" might be
source for code, once you got it mapped somehow, but from past experience you
might not have C. At a guess, you might be able to cobble up a hex loader
from Basic, and from there the eforth approach would help if you could get
something generated for it on another machine, but I really think the
assumption of C is starting from the idea that you are NOT trying to
circumvent limitations but that someone has allowed you the right tools for
the job. So what if the limitations are the product of pointy haired
management? They are still limitations. PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Mon, 18 Apr 2005 18:21:58 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:

>Where I am coming from is something where I might have the very minimal
>bundled stuff, and access to data via peripherals; that "data" might be
>source for code, once you got it mapped somehow, but from past experience you
>might not have C. At a guess, you might be able to cobble up a hex loader
>from Basic, and from there the eforth approach would help if you could get
>something generated for it on another machine,

So how about building the C Parrot on the other machine, and then just
run it on your restricted machine (no hex loader needed, the normal OS
loader should do fine)?

Do you want to tell me that in your environment you have no C on the
other machine, but you have MASM (AFAIK eforth requires MASM; or is
this just for Ting's version?).  That's quite unusual, and I doubt
anyone is going to invest much work on this premise nowadays.
Building Parrot with Parrot, in the classic Forth style, probably has
a better chance, as it has appeal beyond helping a couple of users in
a strange situation.

Quote:
> but I really think the
>assumption of C is starting from the idea that you are NOT trying to
>circumvent limitations but that someone has allowed you the right tools for
>the job.

Well, one tends to avoid things that are not very widely available and
are not too much work to avoid.  E.g., Gforth's Makefiles are
origanized to even work with the broken IRIX and HP/UX "make"s, since
we did not want to require GNU make and it did not take too much work.
But one does take other things for granted: Gforth does require GCC,
though, because avoiding the GNU C dependences would cost too much
programming time and performance.

- anton
--
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html



Tue, 19 Apr 2005 22:51:48 GMT  
 Forth and the Perl 6 virtual machine, Parrot
On Thu, 31 Oct 2002 10:21:58 GMT, Peter Lawrence

Quote:

>I really think the
>assumption of C is starting from the idea that you are NOT trying to
>circumvent limitations but that someone has allowed you the right tools for
>the job. So what if the limitations are the product of pointy haired
>management? They are still limitations. PML.

Then they obviously aren't interested in getting the job done, so
there's no point in spending effort exploring the question of how to
get it done. Spend the effort looking for a better job instead.

--
"Mercy to the guilty is treachery to the innocent."
Remove killer rodent from address to reply.
http://www.esatclear.ie/~rwallace



Wed, 20 Apr 2005 03:31:06 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:


> > The problem here is not C, but the general environment.  If a platform
> > nowadays has no C, it also has no file system.

> I beg to differ. See above - SOMEONE has C, including people who use the very
> same platform you have, but the platform in front of you might not.

That's not a platform in front of you; it's a machine.  The machine might not
have C, but the platform has.

Segher



Tue, 19 Apr 2005 20:52:24 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:

> On Thu, 31 Oct 2002 10:21:58 GMT, Peter Lawrence

> >I really think the
> >assumption of C is starting from the idea that you are NOT trying to
> >circumvent limitations but that someone has allowed you the right tools for
> >the job. So what if the limitations are the product of pointy haired
> >management? They are still limitations. PML.

> Then they obviously aren't interested in getting the job done, so
> there's no point in spending effort exploring the question of how to
> get it done. Spend the effort looking for a better job instead.

Er... that doesn't usually succeed, round here (or where I first hit the
attitudes). What was worth trying, was doing both - looking for a new job,
AND trying to cope with the limitations; only an idiot thinks he can't curse
the darkness and light a candle at the same time. It turned out that the new
job was harder to get - at that time and place, and as it happens, also here
and now. PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Wed, 20 Apr 2005 17:03:54 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:


> >Where I am coming from is something where I might have the very minimal
> >bundled stuff, and access to data via peripherals; that "data" might be
> >source for code, once you got it mapped somehow, but from past experience you
> >might not have C. At a guess, you might be able to cobble up a hex loader
> >from Basic, and from there the eforth approach would help if you could get
> >something generated for it on another machine,

> So how about building the C Parrot on the other machine, and then just
> run it on your restricted machine (no hex loader needed, the normal OS
> loader should do fine)?

> Do you want to tell me that in your environment you have no C on the
> other machine, but you have MASM (AFAIK eforth requires MASM; or is
> this just for Ting's version?).

No.

I am trying to tell you that I do not have any "other machine" - any machine
I have and can make active use of is subject to the same restrictions. I am
aiming at a situation where I can download what is effectively passive data
from elsewhere, but not work on it at that "elsewhere".

(Straight Ting's Forth uses MASM, but the documentation makes it clear that
you really only need the macroing side and you can produce the machine code
as data you embed, even machine code for an unrelated architecture. It struck
me that the same approach can be used with other tools to generate the binary
image, even Basic if necessary. It would be especially nice if you could
provide some of those in Perl, as then you could piggyback on pre-version 6
Perl; if one gets permission to install Perl, one does have that option even
if C has been ruled out for political reasons.)

  That's quite unusual, and I doubt

Quote:
> anyone is going to invest much work on this premise nowadays.

Who said they were making rational investment decisions? People like this are
assuming that programmer effort is a non-cost, because they have to pay the
salary anyway, but actually spending directly will show on a different
budget. They are actually making "rational" responses to a crazy system that
they have learned to work.

I know, it's not a nice place to be - but I've been in it a couple of times
now, so I really am thinking in terms of preparing a sort of emergency
toolkit that will provide a "limp home mode". NOT about getting a "right"
answer - that was ruled out, in the circumstances. I entirely agree about
what is really right; I am just saying that this is about coping when things
are wrong. PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Wed, 20 Apr 2005 17:16:36 GMT  
 Forth and the Perl 6 virtual machine, Parrot

Quote:



> > > The problem here is not C, but the general environment.  If a platform
> > > nowadays has no C, it also has no file system.

> > I beg to differ. See above - SOMEONE has C, including people who use the very
> > same platform you have, but the platform in front of you might not.

> That's not a platform in front of you; it's a machine.  The machine might not
> have C, but the platform has.

> Segher

More semantic quibble! Please stop.

Jerry
--
Engineering is the art of making what you want from things you can get.



Thu, 21 Apr 2005 10:43:10 GMT  
 Forth and the Perl 6 virtual machine, Parrot
.
.
.

Quote:
> Engineering is the art of making what you want from things you can get.
>

That signature seems to have a lot to do with the underlying problems that
got me started with this thread. PML.

--
GST+NPT=JOBS

I.e., a Goods and Services Tax (or almost any other broad based production
tax), with a Negative Payroll Tax, promotes employment.

See http://users.netlink.com.au/~peterl/publicns.html#AFRLET2 and the other
items on that page for some reasons why.



Fri, 22 Apr 2005 10:35:18 GMT  
 
 [ 13 post ] 

 Relevant Pages 

1. More on Forth and the Perl 6 virtual machine, Parrot

2. FORTH on the Java Virtual Machine?

3. Forth Virtual Machine Library in DELPHI available?

4. Forth Virtual Machine Library in C Available?

5. Virtual 8086 Mode/Virtual Machine Monitor (VMM)

6. Virtual 8086 Mode/Virtual Machine Monitor (VMM)

7. SIMPEL Virtual Machine (a toy machine and assembler)

8. Ruby and Parrot in The Perl Review

9. Ruby and Parrot at the 1/16/2002 Boston Perl Mongers meeting

10. Parrot aka Perl 6 info

11. REPOST: Parrot aka Perl 6 info

12. Perl & Python: Parrot

 

 
Powered by phpBB® Forum Software