ROM-able dictionary
DavidM
I've been looking at some of the issues involved in deploying a Forth on
mid-range microcontrollers such as AVR ATMega.
MCU chips such as these have:
- ability to self-program their own flash ROM
- much more flash ROM than RAM - often 8-64k ROM but only around 1-4k RAM
- limited write cycles with ROM - usually around 10k to 100k - after
which the chip needs to be replaced
- Harvard architecture - separate ROM and RAM memory address spaces
In these environments, it seems ideal if at least part of the dictionary
could be stored in ROM. So far, some of the issues involved would be:
- need to simulate a von Neumann architecture, where ROM and RAM are
mapped into a single contiguous space, so that pointers can have a
familiar look-n-feel, but be actioned internally according to what
part of the logical memory map they're pointing in to.
- for words which contain data, such as VALUE, and those created with
CREATE, there would need to be an ability to locate the actual data
outside the ROM area and in RAM. For instance, words in ROM could have
data pointers pointing into RAM, and words like ',' and 'ALLOT' would
consume RAM
- part of the ROM image would be a RAM image, which gets loaded into RAM
on system startup
I'm sure there are a lot more issues to work through. The aim is that the
environment should have as close to a familiar Forth environment as
possible, but make best use of on-chip resources.
Has anyone done work on ROM-based dictionaries?
Cheers
Dave
sp...@controlq.com
> Date: 17 Jul 2008 10:31:59 +1200
> From: DavidM <nos...@nowhere.com>
> Newsgroups: comp.lang.forth
> Subject: ROM-able dictionary
There exist at least a couple of AVR (Atmega/32/48/168) Forths, which have
overcome these issues ... Google is your friend. IIRC, boot loaders on
the Atmega must run from a certain section (there are apnotes available),
which allow onboard code to program the flash directly. An intelligent
forth would have colon take advantage of this to compile directly into
flash ... no?? I have a Butterfly or two which is just screaming out for
a nice forth ... good luck 8-)
Rob.
---- Posted via Pronews.com - Premium Corporate Usenet News Provider ----
http://www.pronews.com offers corporate packages that have access to 100,000+ newsgroups
Elizabeth D Rather
FORTH, Inc. has supported the AVR family with SwiftX for many years,
starting with the 8515 more than 10 years ago and including most of the
modern AT-megas. We run an interactive cross-compiler, that generates
optimized native code for it. We do not consider the AVRs (even the
recent ones) to be a reasonable standalone development environment, and
find using a PC host makes everything much simpler. Our Cross-target
Link provides essentially the same interactive "look and feel" as a
native Forth, with many fewer limitations and awkwardnesses.
SwiftX handles the Harvard architecture just fine, as well as the
management of flash (which contains the executable code) and RAM (both
initialized and uninitialized) plus booting. Evaluation versions are
available.
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."
==================================================
gerard...@gmail.com
Have a look at AMFORTH:
You can play with, look at the sources,
Regards.
Stephen Pelc
>I've been looking at some of the issues involved in deploying a Forth on
>mid-range microcontrollers such as AVR ATMega.
...
> - need to simulate a von Neumann architecture, where ROM and RAM are
> mapped into a single contiguous space, so that pointers can have a
> familiar look-n-feel, but be actioned internally according to what
> part of the logical memory map they're pointing in to.
>Has anyone done work on ROM-based dictionaries?
Lots of people, including Forth Inc, MPE and RAM Technology.
There are two main approaches:
1) Build the Forth using other tools such as a C compiler
or a conventional assembler.
2) Build a Forth cross compiler.
The cross compiler approach is the "better" approach IMHO because
it improves the level of abstraction for the *user*. The downside
is that designing Forth cross compilers requires you to consider
about six time phases. They are very subtle pieces of design.
For small embedded targets the umbilical link approach is common
for interactivity. See www.ram-tech.co.uk for examples.
You want to use an AVR, which is a Harvard machine and increases
tool complexity. We (MPE) have supported 8051, Z8, and AVR. Now
that an ARM such as an LPC210x costs almost the same as an 8051,
I wouldn't suggest an AVR except for very high volume applications.
For low power apps, I would suggest an MSP430.
What is your real objective?
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
Matthias Trute
> - need to simulate a von Neumann architecture, where ROM and RAM are
> mapped into a single contiguous space, so that pointers can have a
> familiar look-n-feel, but be actioned internally according to what
> part of the logical memory map they're pointing in to.
with my amforth I keep the memory pools as they are, it makes surpringly
little trouble. The downside is that I strongly believe that such a
architecture cannot be made 100% ANS94 compliant...
> - for words which contain data, such as VALUE, and those created with
> CREATE, there would need to be an ability to locate the actual data
> outside the ROM area and in RAM. For instance, words in ROM could have
> data pointers pointing into RAM, and words like ',' and 'ALLOT' would
> consume RAM
I designed it differently: CONSTANTs are in the flash, VARIABLEs in the
RAM and VALUEs use the EEPROM address space. Works great.
> - part of the ROM image would be a RAM image, which gets loaded into RAM
> on system startup
You may contact Ron Minke from the Dutch FIG, he has written such a
system for the atmegas.
> Has anyone done work on ROM-based dictionaries?
I'd recommend my amforth.sourceforge.net ;=) Another forth
variant is at krue.net/avrforth.
What can make life difficult is that the atmegas can have more flash
memory than what can be addressed with a 16bit address. Or that the
block buffer words deal with single cell sized block numbers... Ok,
one may increase the cell size to 24bits, but that's unusual
Cheers
Matthias
Mikael Nordman
Hi,
Have look at FlashForth. It is for PIC18Fxxxx.
It maps flash, ram and eeprom into a contiguous address space.
The dictionary entries are always created into flash but you can
choose if the data area is in flash, ram or eeprom.
Andrew Haley
> I've been looking at some of the issues involved in deploying a Forth on
> mid-range microcontrollers such as AVR ATMega.
> MCU chips such as these have:
> - ability to self-program their own flash ROM
> - much more flash ROM than RAM - often 8-64k ROM but only around 1-4k RAM
> - limited write cycles with ROM - usually around 10k to 100k - after
> which the chip needs to be replaced
> - Harvard architecture - separate ROM and RAM memory address spaces
> In these environments, it seems ideal if at least part of the dictionary
> could be stored in ROM. So far, some of the issues involved would be:
> - need to simulate a von Neumann architecture, where ROM and RAM are
> mapped into a single contiguous space, so that pointers can have a
> familiar look-n-feel, but be actioned internally according to what
> part of the logical memory map they're pointing in to.
I have implemented Forth on machines with separate ROM and RAM spaces,
and I don't think a single address space is a good idea. It's easy
enough to use P@, PC@ and so on for code space, and it doesn't
significantly complicate anything.
> - for words which contain data, such as VALUE, and those created
> with CREATE, there would need to be an ability to locate the actual
> data outside the ROM area and in RAM. For instance, words in ROM
> could have data pointers pointing into RAM, and words like ',' and
> 'ALLOT' would consume RAM
Right. Not a problem, IME. DOES> is slightly more complicated
depending on whether the data are in ROM or RAM, but again it's not a
big deal.
Andrew.
Bernd Paysan
> Hi,
> Have look at FlashForth. It is for PIC18Fxxxx.
> It maps flash, ram and eeprom into a contiguous address space.
> The dictionary entries are always created into flash but you can
> choose if the data area is in flash, ram or eeprom.
GForth EC also is rom/flashable. The difference between the two is how to
deal with new definitions: In the ROM case, they have to go to RAM. In the
flash case, you need to spend some additional effort so that you can
compile into flash. One is that you can only clear bits. So you can write
every location only once and you have to prepare the flags (like immediate)
that they are default 1 and can be cleared.
The most tricky thing was LEAVE, because in normal Gforth, the branch
addresses of LEAVE are used to link the LEAVEs together. The flashable
version looks for all unresolved branches back to the LOOP's cooresponding
DO, but that doesn't allow tricks like DO ... WHILE ... LOOP ELSE ...
--
Bernd Paysan
"If you want it done right, you have to do it yourself"
http://www.jwdt.com/~paysan/
Mikael Nordman
> DavidM <nos...@nowhere.com> wrote:
>
>> I've been looking at some of the issues involved in deploying a Forth on
>> mid-range microcontrollers such as AVR ATMega.
>
>> MCU chips such as these have:
>> - ability to self-program their own flash ROM
>> - much more flash ROM than RAM - often 8-64k ROM but only around 1-4k RAM
>> - limited write cycles with ROM - usually around 10k to 100k - after
>> which the chip needs to be replaced
>> - Harvard architecture - separate ROM and RAM memory address spaces
>
>> In these environments, it seems ideal if at least part of the dictionary
>> could be stored in ROM. So far, some of the issues involved would be:
>
>> - need to simulate a von Neumann architecture, where ROM and RAM are
>> mapped into a single contiguous space, so that pointers can have a
>> familiar look-n-feel, but be actioned internally according to what
>> part of the logical memory map they're pointing in to.
>
> I have implemented Forth on machines with separate ROM and RAM spaces,
> and I don't think a single address space is a good idea. It's easy
> enough to use P@, PC@ and so on for code space, and it doesn't
> significantly complicate anything.
In FlashForth it is quite convinient to have just one address space.
You dont need several versions of words that address different types of
memory (CMOVE, DUMP, ALLOT, etcetera).
The address virtualisation is embedded into @, !, so the programmer
needs to take care not to write to flash/eeprom too often.
The flash blocks are erased and updated automatically as needed.
>
>> - for words which contain data, such as VALUE, and those created
>> with CREATE, there would need to be an ability to locate the actual
>> data outside the ROM area and in RAM. For instance, words in ROM
>> could have data pointers pointing into RAM, and words like ',' and
>> 'ALLOT' would consume RAM
>
> Right. Not a problem, IME. DOES> is slightly more complicated
> depending on whether the data are in ROM or RAM, but again it's not a
> big deal.
With the FlashForth memory model, CREATE, ALLOT, ',' refer to the
current type of data area, which is set by the words FLASH, EEPROM, RAM.
You can use the same defining word to create tables in all types of
memory, and you can also manipulate the data with the same words
in all types of memory.
This makes programming easier and the code looks cleaner.
The resulting code is a bit slower, the ram read/write goes from 12
cycles to 16 cycles due to the address virtualisation on the PIC18F.