Executing code directly from Flash ROM

[fig8r]

From thread about "locals":
>> to use external SRAM at an effective 7µs
(from ROM) or 10µs (from RAM)/word access; whereas here I use internal
RAM at 2µs/word access (the instruction execution speed).

I was wondering if it is known how different is Flash ROM speed compared to SRAM?

The reason I am asking is that I had a crazy idea to consider compiling Forth into ROM and executing it from there directly.

To an extent, it's probably already happening with on-chip ROM, as in case of Editor etc.

There are interesting implications:
- about the Dictionary (word list); possibly a form of persistent directory; or dynamically built at the start scanning ROM -- on-chip ROM bootstraps word list too
- increasing memory space by freeing up SRAM for data only and making the whole ROM available for code, meaning larger programs -- basically like a SmallTalk machine; word reference could still be index based to keep within 2 bytes, de-referenced to ROM location in the word list.
- would the same assumptions apply is the Flash ROM would be SD card? ...basically the same SPI interface

[Julz]

>> to use external SRAM at an effective 7µs 

(from ROM) or 10µs (from RAM)/word access; whereas here I use internal
RAM at 2µs/word access (the instruction execution speed).

What the comment meant was that the code for accessing locals would then run from internal Flash, but would be accessing external RAM and that'd take 7µs per word.

 

I was wondering if it is known how different is Flash ROM speed compared to SRAM?

For internal Flash, there's not much difference between that and SRAM for sequential code. However, whenever we need a non-sequential access such as a memory fetch or a jump; then the SRAM has a big overhead because you have to finish the current read; send out a new command; follow it with an address and then you're ready to access the data. So that's at least 4µs used up, and of course once that's done you have to resume normal execution which means sending out another command etc. Hence it takes about 10µs in those cases (it only adds about 6µs for a jump though).

 

The reason I am asking is that I had a crazy idea to consider compiling Forth into ROM and executing it from there directly.

To an extent, it's probably already happening with on-chip ROM, as in case of Editor etc.

Yes; apart from the byte-code VM (which is in AVR assembler), the whole of FIGnition's Forth system - the additional words; the interpreter; the compiler; many arithmetic routines; the editor; the external Flash Translation layer; a number of tape routines are written in Forth and compiled into internal Flash.

 

There are interesting implications:
- about the Dictionary (word list); possibly a form of persistent directory; or dynamically built at the start scanning ROM -- on-chip ROM bootstraps word list too
- increasing memory space by freeing up SRAM for data only and making the whole ROM available for code, meaning larger programs -- basically like a SmallTalk machine; word reference could still be index based to keep within 2 bytes, de-referenced to ROM location in the word list.
- would the same assumptions apply is the Flash ROM would be SD card? ...basically the same SPI interface

So, I think what you're really asking is whether its possible to execute code in place on external Flash and / or internal Flash. That way you'd be able to use the SRAM entirely for data.

Well, it's kinda possible. Here's the constraints:

1. The internal Flash space on the AtMega168 version of FIGnition is entirely used up, so there's no more space for additional commands (though I plan to produce an incremental update to FIGnition which optimises some of the CRC code and tape routines so that there's space for a few more double-integer commands).

2. On the AtMega328 there's a bit more internal Flash space for Forth. It's constrained however because it can only run in the region: 0x5500 to 0x6FFF giving space for a ROM up to 6912b.

3. It is possible to save compiled Forth as blocks on external Flash - i.e. a program. But you can't run them from external Flash; instead you have to load the image into RAM first.

4. It is possible to re-write the VM so that the Forth ROM itself is in external Flash. In particular, the external Flash area from 0x2000 to 0x7FFF happens to be free on both processors for all Flash variants. This would increase the effective space for the Forth ROM to about 11Kb and it would also free up another 6Kb for AVR code running from internal Flash on AtMega168 and AtMega328 FIGnitions. The downside is that execution speed for external Flash would be slower, for the same reasons as for slower SRAM speed (except that there's an extra address byte so it's 25% to 33% slower whenever random-access is required). However, sequential access might be slightly faster due to not having to determine whether to switch to internal ROM vs external SRAM.

5. In all cases, FIGnition's address space is 64Kb. We can't practically have more than 32Kb space for ROM, 32Kb space for RAM.

SD Cards aren't supported in FIGnition. There are a few reasons for this:

1. The SD protocol isn't open. You have to pay money to join a club to find out the codes properly. I think that's immoral, so I don't support it.

2. The SD protocol is a moving target, the latest version requires exFAT support in your system. I would sooner support protocols that are less likely to change.

3. The SD protocol is a big protocol; it would rule out the use of an AtMega168.

Although popular - VERY popular - SD cards are part of the trend towards privatising information: USB, SD, HDMI etc. They're all just data over wires, but the format of the data is *owned*. It's like someone suddenly deciding that you have to pay money just to talk in English or that the kinds of things you want to talk about have different prices.

Very undemocratic. To me, very disturbing.

But if someone else wants to do that, then of course, they're free to do support SD cards through FIGnition!

-cheers from Julz