Forth bootstrapping framework - Bootforth
jpb
I wrote a small but handy framework in C for
bootstrapping a Forth system, thus for
creating a "Forth Kernel". Hence the name,
even when it's already taken by a Forth
boot-loader for BSD systems(when you know a
better name let me know it).
How do you create a "Forth Kernel", thus a
small forth system for building the rest of the
system? You write your custom primitives in C,
add a bit of your own startup code to it,
compile it and then you have the "Forth Kernel".
Why? Because I wanted to start my own
forth system through writing in itself, without
ANS Forths, etc. flavor in it, just my own
ideas.
Whoever is interested into it:
http://gitorious.org/projects/bootforth
I'm interested in your opinions or ideas about it.
Greetings
-jpb
sp...@controlq.com
Bernhart(?),
I just didn't want to think that your posting went un-answered/challenged.
I downloaded this onto an Ubuntu 8.04 laptop, and had a quick go at it.
It was a bit disconcerting to have to go from the top source dir into a
subdir to find the make file, but it did compile very quickly.
Rudimentary, and geared to a C based approach, but it is interesting, and
appears to be quick and portable to just about any Unix, 'BSD, Linux, or
even Windoze (character based) platform.
Oh, and about the name ... BootForth might be a tad misleading, and
perhaps the name should imply an "embedded" variant rather than the
ability to "boot" a system. I initially thought it was something other
than it was ... but clearly you intend this as an embedded language for
larger projects, no??
Also, you dismiss (somewhere) the idea of an ANS standard for "your own
ideas". That's fine, but it will not assist widespread adoption if you
can't pass some level of ANS compliance, IMHO. Simply classify your
experimental "extensions" as such, and implement a minimum "core" wordset
to give those who might use your project some familiar ground ... beyond
that, you aren't limited in where your imagination takes it.
I can see a number of possible uses for it. I'm sure as it evolves, and
docs are added it will develop a following of some sort ... good luck
8-), and keep up the good work ...
Cheers,
Rob Sciuk
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups
Nickolai Leschov
> I'm interested in your opinions or ideas about it.
Hi, I've just built the sample on Windows and it works! I already had
mingw and git installed.
I totally understand your idea. I will look into the source now.
Do you think it's possible to make BootForth run on an embedded system
with 1.5K of RAM and 32K of ROM?
Best wishes,
Nickolai Leschov
jpb
> Hi, I've just built the sample on Windows and it works! I already had
> mingw and git installed.
> I totally understand your idea. I will look into the source now.
Hopefully you understand it. Because most people who I'm talking to
about it, don't get the point of it at the first explanation try.
Well, I should take a better name than "BootForth", even when it means
in that case bootstrapping a Forth System and not booting a computer.
> Do you think it's possible to make BootForth run on an embedded system
> with 1.5K of RAM and 32K of ROM?
At the current moment, I don't think so. It depends on a couple of
standard C functions which need something like a library.
But why, should you want to run BootForth on an
embedded system with those limitations?
For the joy? Or because you can? Both are good targets
and probably it would fit into the ROM, but the RAM
is too small and it assumes the whole memory space
for it's own, which means that it's not ROM-able.
But probably by tweaking it, you could come to
that point of making it ROM-able.
At the moment I don't have the urgent need to make it ROM-able,
because I write my own Forth system using BootForth, with which
I intend to make games/demos.
Greetings,
- jpb
Bruce McFarling
> Well, I should take a better name than "BootForth", even when it means in that case bootstrapping a Forth System and not booting a computer.
Maybe the fact that "BootXYZ" is normally read as meaning booting the
computer is the problem.
Forthstrap?
Jonah Thomas
> Well, I should take a better name than "BootForth", even when it means
> in that case bootstrapping a Forth System and not booting a computer.
Maybe call it BootstrapForth?
Nickolai Leschov
>> Do you think it's possible to make BootForth run on an embedded system
>> with 1.5K of RAM and 32K of ROM?
> At the current moment, I don't think so. It depends on a couple of
> standard C functions which need something like a library.
in C. (sometimes, C++ even) Therefore, there is standard library. I hope
that there would be just a few things to consider to be able to run
Forth on a microcontroller; here's the ones that come to mind:
1. Using malloc/free is impractical, even though it may be implemented
in standard library.
2. IO device is a serial line, which may be used by the application as
well. Again, this may or may not be accounted for in the implementation
of the standard library.
> But why, should you want to run BootForth on an
> embedded system with those limitations?
umbilical Forth on such system. Currently I'm stuck with C's
edit/compile/test cycle. In-curcuit debugging is not available and
programming (writing binary code) is not instantaneous and is apart from
running. I used to use Forth in the past and I'd like to use Forth's
interactivity in my embedded project.
> probably it would fit into the ROM, but the RAM
> is too small
Maybe I should do some tweaks. I don't yet have the whole picture of how
BootForth could be used in such environment but I think that umbilical
Forth will be very useful for embedded environment if done right.
> and it assumes the whole memory space
> for it's own, which means that it's not ROM-able.
I didn't get it. Could you please elaborate on this?
I like your approach that Forth is made for tweaking and extending it. I
liked to use Forth, and thought about rolling my own, but never got to
the point where I can do it myself. Now I don't have to!
Best regards,
Nickolai Leschov
Maki
news:g6s397$kac$1...@aioe.org...
I didn't look at BootForth's code but I think that this system can't work on
micros with Harvard architecture. These microcontrollers usually have lots
of flash memory and little RAM (as described). So You need Forth with
modifications according to which memory your code is addressing.
Look at FlashForth, amForth...
Best regards,
Maki
Elizabeth D Rather
> jpb wrote:
>>> Do you think it's possible to make BootForth run on an embedded
>>> system with 1.5K of RAM and 32K of ROM?
>> At the current moment, I don't think so. It depends on a couple of
>> standard C functions which need something like a library.
Assuming you have flash instead of real ROM, it's quite possible in
SwiftX (which doesn't use any C).
...
>> But why, should you want to run BootForth on an embedded system with
>> those limitations?
> I think Forth could fit such systems. I would like to be able to use
> umbilical Forth on such system. Currently I'm stuck with C's
> edit/compile/test cycle. In-curcuit debugging is not available and
> programming (writing binary code) is not instantaneous and is apart from
> running. I used to use Forth in the past and I'd like to use Forth's
> interactivity in my embedded project.
You should really check out one of the evaluation versions of SwiftX and
see how its umbilical system works.
>> probably it would fit into the ROM, but the RAM is too small
> Maybe I should do some tweaks. I don't yet have the whole picture of how
> BootForth could be used in such environment but I think that umbilical
> Forth will be very useful for embedded environment if done right.
>> and it assumes the whole memory space for it's own, which means that
>> it's not ROM-able.
I also recommend that you read the proposed cross-compiler standard at:
http://www.forth.com/downloads/ANS/XCtext5.doc (normative text,
http://www.forth.com/downloads/ANS/XCtext5.pdf two formats)
http://www.forth.com/downloads/ANS/XCapp5.doc (explanatory appendices,
http://www.forth.com/downloads/ANS/XCapp5.pdf two formats)
http://www.forth.com/downloads/ANS/XCpaper.pdf (overview)
Cheers,
Elizabeth
--
==================================================
Elizabeth D. Rather (US & Canada) 800-55-FORTH
FORTH Inc. +1 310.999.6784
5959 West Century Blvd. Suite 700
Los Angeles, CA 90045
http://www.forth.com
"Forth-based products and Services for real-time
applications since 1973."
==================================================
rickman
These appear to be exactly the same as the ones I downloaded in 2004.
Has no progress been made in four years??? What has to happen for
these documents to become standard? Is that expected to happen?
Also, for what it is worth, I see the character set at the bottom of
every page. Considering that many of these characters are actually
words in Forth, having them at the bottom of ***EVERY*** page makes it
impossible to search for them in a PDF file. Is there a real need to
have this guide on every page? Can't it just be on one page where
people can find it and not interfere with searches?
Rick
rickman
>
> Also, for what it is worth, I see the character set at the bottom of
> every page. Considering that many of these characters are actually
> words in Forth, having them at the bottom of ***EVERY*** page makes it
> impossible to search for them in a PDF file. Is there a real need to
> have this guide on every page? Can't it just be on one page where
> people can find it and not interfere with searches?
>
> Rick
Of course, this question is not directed specifically to Elizabeth,
but to anyone involved in the standards process.
Rick
Stephen Pelc
<nles...@gmail.com> wrote:
>Do you think it's possible to make BootForth run on an embedded system
>with 1.5K of RAM and 32K of ROM?
An MPE cross compiler can build a full interactive Forth in
that space! There's an MSP430 somewhere on my desk ...
Stephen
--
Stephen Pelc, steph...@mpeforth.com
MicroProcessor Engineering Ltd - More Real, Less Time
133 Hill Lane, Southampton SO15 5AF, England
tel: +44 (0)23 8063 1441, fax: +44 (0)23 8033 9691
web: http://www.mpeforth.com - free VFX Forth downloads
Brad Eckert
>
> These appear to be exactly the same as the ones I downloaded in 2004.
> Has no progress been made in four years??? What has to happen for
> these documents to become standard? Is that expected to happen?
They are a defacto standard. They are openly published, have reached
consensus among the commercial Forth vendors, and have been in use a
long time without many complaints.
-Brad
Elizabeth D Rather
>> I also recommend that you read the proposed cross-compiler standard at:
>>
>> http://www.forth.com/downloads/ANS/XCtext5.doc (normative text,
http://www.forth.com/downloads/ANS/XCtext5.pdftwo formats)
http://www.forth.com/downloads/ANS/XCapp5.doc(explanatory appendices,
http://www.forth.com/downloads/ANS/XCapp5.pdftwo formats)
http://www.forth.com/downloads/ANS/XCpaper.pdf(overview)
> These appear to be exactly the same as the ones I downloaded in 2004.
> Has no progress been made in four years??? What has to happen for
> these documents to become standard? Is that expected to happen?
>
> Also, for what it is worth, I see the character set at the bottom of
> every page. Considering that many of these characters are actually
> words in Forth, having them at the bottom of ***EVERY*** page makes it
> impossible to search for them in a PDF file. Is there a real need to
> have this guide on every page? Can't it just be on one page where
> people can find it and not interfere with searches?
>
> Rick
These drafts were taken through 5 revisions during a period in which we
received much helpful comment & discussion. We haven't heard any
further comments since v.5, and so, you're quite right, there haven't
been any more changes.
As Stephen says, it's a de facto standard. If the current standards
group would like to bless it, that would be lovely.
As for the footer: that was copied from the practice in ANS Forth, to
show the collating sequence. I have no particular love for it, and if
the committee wants to toss it that's fine. But if you specify "whole
word" in Acrobat's search function when you're looking for something
like I (or even type <space>I<space>) it'll work.
rickman
> rickman wrote:
> > On Jul 31, 1:30 pm, Elizabeth D Rather <erat...@forth.com> wrote:
> ...
> >> I also recommend that you read the proposed cross-compiler standard at:
>
> >>http://www.forth.com/downloads/ANS/XCtext5.doc (normative text,
>
>
> > These appear to be exactly the same as the ones I downloaded in 2004.
> > Has no progress been made in four years??? What has to happen for
> > these documents to become standard? Is that expected to happen?
>
> > Also, for what it is worth, I see the character set at the bottom of
> > every page. Considering that many of these characters are actually
> > words in Forth, having them at the bottom of ***EVERY*** page makes it
> > impossible to search for them in a PDF file. Is there a real need to
> > have this guide on every page? Can't it just be on one page where
> > people can find it and not interfere with searches?
>
> > Rick
>
> These drafts were taken through 5 revisions during a period in which we
> received much helpful comment & discussion. We haven't heard any
> further comments since v.5, and so, you're quite right, there haven't
> been any more changes.
>
> As Stephen says, it's a de facto standard. If the current standards
> group would like to bless it, that would be lovely.
Ok, so it can be used without fear of being changed at later date? It
just seems odd that a standards body would stop short of making
something like this an actual standard.
> As for the footer: that was copied from the practice in ANS Forth, to
> show the collating sequence. I have no particular love for it, and if
> the committee wants to toss it that's fine. But if you specify "whole
> word" in Acrobat's search function when you're looking for something
> like I (or even type <space>I<space>) it'll work.
Yes, it works for "words", but many Forth words are not words in that
they don't use letters. For example, if I search for "!" with "Whole
words only" selected, I still get every page with the footer which is
every odd page between 35 and 133 in the 94 DPANS doc. Actually, this
is the one time that I prefer the list based search results of Acrobat
6 over the "show one at a time" result of Acrobat 5 and earlier.
I don't expect this to be an issue for using the cross compiler
standard, but it has been a PITA for using the 94 DPANS document for
those of us who actually need to look up words from time to
time. :^)
Not trying to rag on you, this just seemed like a good time to mention
it.
Rick
Nickolai Leschov
> An MPE cross compiler can build a full interactive Forth in
> that space! There's an MSP430 somewhere on my desk ...
I would be happy to try it. But as far as I can tell, it doesn't work on
PICs, does it? (I'm not a fan of this architecture, that's just what
we've got now)
I fully understand that a Forth system _can_ work on such hardware. I'm
just looking for the one that actually works. My original interest in
BootForth was because of its assumed portability and extendability (I
can and should implement words in C)
Regards,
Nickolai
Nickolai Leschov
> Assuming you have flash instead of real ROM, it's quite possible in
> SwiftX (which doesn't use any C).
C and BootForth's structure is beneficial if Forth doesn't run on my
hardware as it is and has to be customized anyway.
> You should really check out one of the evaluation versions of SwiftX and
> see how its umbilical system works.
SwiftX for PIC architecture, so I can't possibly end up using SwiftX in
my project, can I?
> I also recommend that you read the proposed cross-compiler standard at:
> ... skipped ...
Thanks, I'll look into it.
Regards,
Nickolai
Stephen Pelc
wrote:
>Ok, so it can be used without fear of being changed at later date? It
>just seems odd that a standards body would stop short of making
>something like this an actual standard.
As far as ANS was concerned, it was too late, we were too tired,
and the request came very late in the process.
As far as Forth200x is concerned, I'm minded to include the cross
compiler standard as is - it's stood the test of time, and both
Forth Inc. and MPE support it. However, there are other lower level
proposals to deal with first.
Stephen Pelc
<nles...@gmail.com> wrote:
>Stephen Pelc wrote:
>> An MPE cross compiler can build a full interactive Forth in
>> that space! There's an MSP430 somewhere on my desk ...
>
>I would be happy to try it. But as far as I can tell, it doesn't work on
>PICs, does it? (I'm not a fan of this architecture, that's just what
>we've got now)
Apart from a truly awful CPU design, PICs suffer because the price
people are prepared to pay for PIC tools is way too low - we've
considered them for years, but the commercial benefit just hasn't
been there. There are at least two "free" Forths out there, and
RAM Technology was selling an IRTC Forth. Forth tools are available
for PICs, but I haven't used them.
Nowadays, unless you are building in huge volumes, an MSP430,
9S12 or ARM is going to save a fortune in software development
costs at the expense of a few pennies in hardware costs.
Nickolai Leschov
> Apart from a truly awful CPU design, PICs suffer because the price
> people are prepared to pay for PIC tools is way too low - we've
> considered them for years, but the commercial benefit just hasn't
> been there. There are at least two "free" Forths out there, and
> RAM Technology was selling an IRTC Forth. Forth tools are available
> for PICs, but I haven't used them.
>
> Nowadays, unless you are building in huge volumes, an MSP430,
> 9S12 or ARM is going to save a fortune in software development
> costs at the expense of a few pennies in hardware costs.
What is your point? That PIC is not a nice platform? I agree with you on
this. However, at this moment I am not in a position to choose a
platform. I seek the better development tools for the one I got.
As far as I understand, MPE Ltd. does not offer Forth for PIC, but RAM
Technology does.(or did? their site looks dated) Thanks for mentioning them.
Regards,
Nickolai
Elizabeth D Rather
>> These drafts were taken through 5 revisions during a period in which we
>> received much helpful comment & discussion. We haven't heard any
>> further comments since v.5, and so, you're quite right, there haven't
>> been any more changes.
>>
>> As Stephen says, it's a de facto standard. If the current standards
>> group would like to bless it, that would be lovely.
>
> Ok, so it can be used without fear of being changed at later date? It
> just seems odd that a standards body would stop short of making
> something like this an actual standard.
As I recall, there was only one minor technical change since the first
draft, and that very early on. Most of the work has been in clarifying
the normative and non-normative language in response to questions and
suggestions.
The technology itself was designed jointly by MPE and FORTH, Inc. based
on past work with cross-compilers in both companies in prior years.
It's quite stable, and very successful.
There actually is very little in the standard itself about the umbilical
connection. That would be a nice addition (and wouldn't require
lower-level changes), but I don't see investing the effort unless
there's a demand.
>> As for the footer: that was copied from the practice in ANS Forth, to
>> show the collating sequence. I have no particular love for it, and if
>> the committee wants to toss it that's fine. But if you specify "whole
>> word" in Acrobat's search function when you're looking for something
>> like I (or even type <space>I<space>) it'll work.
>
> Yes, it works for "words", but many Forth words are not words in that
> they don't use letters. For example, if I search for "!" with "Whole
> words only" selected, I still get every page with the footer which is
> every odd page between 35 and 133 in the 94 DPANS doc. Actually, this
> is the one time that I prefer the list based search results of Acrobat
> 6 over the "show one at a time" result of Acrobat 5 and earlier.
>
> I don't expect this to be an issue for using the cross compiler
> standard, but it has been a PITA for using the 94 DPANS document for
> those of us who actually need to look up words from time to
> time. :^)
>
> Not trying to rag on you, this just seemed like a good time to mention
> it.
It's a fine time. Ask the 200x committee to remove it, if they haven't
already.
Elizabeth D Rather
> Elizabeth D Rather wrote:
> > Assuming you have flash instead of real ROM, it's quite possible in
>> SwiftX (which doesn't use any C).
> Yes, it's Flash actually.
> C and BootForth's structure is beneficial if Forth doesn't run on my
> hardware as it is and has to be customized anyway.
>> You should really check out one of the evaluation versions of SwiftX
>> and see how its umbilical system works.
> I would be happy to, but as far as I can see, there isn't a version of
> SwiftX for PIC architecture, so I can't possibly end up using SwiftX in
> my project, can I?
It's true, SwiftX doesn't run on any of the PICs. The reason I
suggested taking a look was your statement,
"I would like to be able to use umbilical Forth on such system.
Currently I'm stuck with C's edit/compile/test cycle. In-curcuit
debugging is not available and programming (writing binary code) is not
instantaneous and is apart from running. I used to use Forth in the past
and I'd like to use Forth's interactivity in my embedded project."
If you or the author of one of the existing PIC Forths would like to
implement an umbilical, it would be useful to follow an existing model.
If you have access to any of the parts that SwiftX does support, you
could try it and get a feel for how it works, not to mention reading the
documentation.