Irreproducible error in batch mode? FF5.0, ATMega328 (Arduino Nano)

[Jindrich Vavruska]

Hello, I have yet another experience with FF on ATmega, this time it does not look trivial.

I wrote a library to play with LCD display with PCD8544 (Nokia 5110). Everything works as expected except one weird thing: when I send the forth file to ATmega, and error occurs during compilation of the same word:

It is always in the same word when compiling the same word, although the file itself was slightly modified in the meantime, so it is not the same line as originally, yet the same place.

The words preceding the error are:

(starting from line 110, I will post the full file in a separate post)

\ send a byte to SPI
: lcd.cmd 
  [ lcd:cmd lcd:enable or ] literal
  portb mclr  \ set enable and D/C line to command (low)   
;

marker --test1

: lcd.basic ( -- ) set:basic spi.send ; inlined
: lcd.ext   ( -- ) set:ext   spi.send ; inlined 

: lcd.setx  ( x-col -- ) 
  $7f and $80 or spi.send 
;

: lcd.sety ( y-row -- )
  $3f and $40 or spi.send 
;

: lcd.atxy ( x y -- )
  lcd.cmd lcd.basic
  lcd.sety lcd.setx
;

When it is compiling lcd.atxy, after lcd.cmd lcd.basic the error occurs:

> : lcd.atxy ( x y -- )
>   lcd.cmd lcd.basic  56962 57251 24320 AD?

The three addresses are $DE82, $DFA3 and $5F00, respectively.

The communication apparently freezes. However, when I reset the arduino using the onboard reset button,
I get the FF welcome banner E FlashForth 5 ATmega328P 02.07.2016 and then the rest of the compilation response (all words following the failed lcd.atxy) and words show that everything is compiled except lcd.atxy

One interesting thing is that if I type the missing word by hand, it compiles without error...

The most interesting thing, however, is that the error disappears when I comment out the inlined keyword (everything else is the same):

: lcd.basic ( -- ) set:basic spi.send ; inlined
: lcd.ext   ( -- ) set:ext   spi.send ; inlined 

I thought I understood inlined but I seem to have been wrong.

As I continue thinking about it, the constants set:basic and set:ext themselves are already inlined... I use them only in these two words, so I will let them out in the next version.

Did I overkill the compilation by too much inlining? :-D

[Jindrich Vavruska]

And I forgot to mention that I used ff-shell.py, USB port and the Arduino nano apparently uses FT232 as USB-serial converter, if it matters.

[Jindrich Vavruska]

Here is the full file... Slightly refactored version vs. the one I used when typing the post.

[Mikael Nordman]

Well,
The FF inlining is very simple.
It can only inline words that contain position independent assembly code that ends with a return.

If a word contains rcall or ends with jmp, etc.. the inlining process goes to pieces.

Something like this shud work:

$25 constant portb inlined
$01 constant clk inlined
: set.clk clk portb inline mset ; inlined

set.clk will now be inlined correctly when it is compiled.
If you use 'mset' without the 'inline', the set.clk word will end in 'jmp mset'
and the inling of set.clk result in the problems that you have.

So in your case the inlining breaks because spi.send is not inlined or inlineable since is it is calling c! and mtst.
if you inline c! and mtst and spi.send, it might work to also inline.

But if it is speed you want I would use assembly or the BIT words.
The BIT words compile very fast code, just one or two assembly instructions are generated. See bit.txt.

If you need speed and save memory, then you can just

: set.clk [ %10011010.AAAAA.bbb i, ] ; inlined \ SBI instruction

Where AAAAA contains the portb I/O address and bbb the bit address.