|
|
 Up |
|
|
  |
Author: DavidMDavidM Date: Jul 16, 2008 15:31
Hi,
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.
|
| Show full article (1.53Kb) |
|
| | 9 Comments |
|
|
Author: spamspam Date: Jul 16, 2008 19:40
On Wed, 17 Jul 2008, DavidM wrote:
> Date: 17 Jul 2008 10:31:59 +1200
> From: DavidM nowhere.com>
> Newsgroups: comp.lang.forth
> Subject: ROM-able dictionary
>
> Hi,
>
> I've been looking at some of the issues involved in deploying...
|
| Show full article (2.39Kb) |
|
| | no comments |
|
|
Author: Elizabeth D RatherElizabeth D Rather Date: Jul 16, 2008 23:32
DavidM wrote:
> Hi,
>
> 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. ...
|
| Show full article (2.76Kb) |
| no comments |
|
|
Author: gerardsontaggerardsontag Date: Jul 17, 2008 01:19
On 17 juil, 00:31, DavidM nowhere.com> wrote:> Hi,
>
> 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. ...
|
| Show full article (1.74Kb) |
| no comments |
|
|
Author: Stephen PelcStephen Pelc Date: Jul 17, 2008 01:33
On 17 Jul 2008 10:31:59 +1200, DavidM 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.
...
> - 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.
|
| Show full article (1.71Kb) |
| no comments |
|
|
Author: Matthias TruteMatthias Trute Date: Jul 17, 2008 08:07
David,
> - 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.
|
| Show full article (1.55Kb) |
| no comments |
|
|
Author: Mikael NordmanMikael Nordman Date: Jul 19, 2008 09:10
DavidM kirjoitti:
> Hi,
>
> 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. ...
|
| Show full article (1.90Kb) |
| no comments |
|
|
Author: Andrew HaleyAndrew Haley Date: Jul 19, 2008 10:14
DavidM 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.
|
| Show full article (1.62Kb) |
| no comments |
|
|
Author: Bernd PaysanBernd Paysan Date: Jul 19, 2008 13:34
Mikael Nordman wrote:
> 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 ...
|
| Show full article (1.06Kb) |
| no comments |
|
|
|
|
|
Author: Mikael NordmanMikael Nordman Date: Jul 20, 2008 03:57
Andrew Haley kirjoitti:
> DavidM 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. ...
|
| Show full article (2.61Kb) |
| no comments |
|
|
