STM8 architects some 16bit on top of the ST7 6800-like architecture (at least some fast arithmetic instructions), and the address space for programs was extended by 24bit "Far adressing".

Unfortunately, access to the "Far" 24bit memory space (in practice it's just 19bit [see edit]) is only possible for the following instructions:

• 8 bit load/store instructions, limited to "absolute" and "indirect addressing" memory access
• Jump, call and interrupt vectors for code access

That's OK since RAM and EEPROM are in an 8bit (zero page) or 16bit memory space, and it doesn't matter where they're executed. Forth, however, cares a lot about ROM addresses: as XTs (Execution Tokens) are data, too, there is no easy way to put "threaded Forth code" into 32K to 96K Flash memory in the extended address space of "High Density" devices like STM8S207 or STM8L162.

In Forth, the address space can be used for (carefully crafted) interrupt service routines (there is no need to keep these in the dictionary), and for library code written Forth, assembler or C that has an entry point in the 16bit address space.

Using the STM8 eForth compiler for creating code that runs in the Far address space must take care not to use anything that's based on BRANCH, ?BRANCH or 16 bit addresses on the data stack (that is IF, ELSE, THEN, BEGIN, UNTIL, WHILE REPEAT, FOR, AFT, NEXT, DO, LOOP...).

That doesn't mean that it's impossible, though: by compiling code that only uses words from 16 bit ROM to RAM and that's limited to relative addressing for control structures, and then copying that code to Far memory, it should work. Anchoring such structures in the 16 bit address space would, of course, still be necessary. 

At least, from release 2.2.26.pre1 on,  STM8 eForth provides the words FC@ and FC! for accessing memory in the far address space. Words for moving memory between Far memory and the 16bit address space (using block programming and transfer) are planned. As Flash block write code must be executed from RAM, the whole thing is a bit more complicated. As soon as that's available, some of the advanced use cases can be addressed.

EDIT: I used to believe that the address space is 18bit but there is evidence that there were STM8AF51B High Density devices on offer with 256K Flash memory (and 12K RAM, two I2C, two SPI, 3 x UART, 4x16bit timer... ). References to it have almost disappeared since.