amforth-devel — Development discussion and user support

Re: [Amforth-devel] How TO - dict_x for bigger atmegas

[pito <pi...@vo...>]

Michael, thanks! So there are dependencies..
Provided the xx.asm files contains an .org or something like that
the dict_ file must not be organised specificly, maybe..

E.g. first idea:
########## do not touch >>>>>>>>>>>>
dict_core.inc
dict_appl_core.inc
########## <<<<<< do not touch #####
above .incs are called by amforth.asm!!

"dict_big.inc" (following xx.inc means the content of
it,cleaned,merged):
*******************
dict_mcu.inc
dict compiler.inc
dict_usart.inc
dict_vm.inc
dict_wl.inc
user.inc
device.inc (? not needed??, why it does exist? why it defines words
as variables when those are constants (various reg addr)? - I am not
setting "WANT_" but loading atmega1284p.frt instead, thus this frt
would be fine to have in asm...)
words\*.asm 
*******************

Not sure about device.inc. Why we need it?

Pito

Re: [Amforth-devel] How TO - dict_x for bigger atmegas

[Kalus M. <mic...@on...>]

Hi Pito.

Am 19.09.2010 um 02:11 schrieb pito:
..
> As Matthias indicates there are
> no dependencies on positioning of the asm within the chip (?),
..

i! had to be in boot flash section. Interrupt vectors had to be at  
the _beginning_ of application flash section (or boot flash section;  
depending on fuse setting).
Is that still true for 1284p?

All other amforth words are independent and may be compiled in any  
order you like - theoreticaly. ;-)

On atmega168 and other smaler micros quite a few words resided in  
boot flash section too, and where coded with NEAR relativ jumps  
(amforth3.6). Those could reach a range of (PC-(2K+1)) to (PC+2K)  
cells. Some of them addressed i! so they had to stay in boot section  
flash. And some of them adressed the inner interpreter this way, so  
they had to be near NEXT, which was in boot sector too. If you put  
those words some where else, your assembler (AVRA?) will stop with an  
error message. Thats why there was no simple way to make a bootloader  
independent of amforth (Arduinos).


See amforth-3.6:
dict_appl_core.inc
dict_core.inc
"; this part of the dictionay has to fit into the nrww flash
  ; section together with the forth inner interpreter."
Words of these two files had to stay where they where supposed to be.



Now lets see if this is still true with amforth-4.1.?
You may grep rjmp instructions in the amforth tree to find out this  
kind of dependencies.

I found:
PowerBook:~/amforth/amforthQuellen/amforth-4.1 michael$ grep -i -R  
rjmp core/*.* appl/*.* appl/atmega2561/*.* appl/atxmega/*.*
core/amforth-low.asm:    rjmp DO_NEXT
core/amforth-low.asm:    rjmp DO_EXECUTE
core/amforth.asm:    rjmp DO_NEXT
core/amforth.asm:    rjmp DO_EXECUTE
PowerBook:~/amforth/amforthQuellen/amforth-4.1 michael$

In both files rjmp is inside of inner interpreter.
If you load this or that file depends on you configuration.

Looks like there are no such dependencies any more in all other words.

Michael




  
     

Re: [Amforth-devel] How TO - dict_x for bigger atmegas

[Kalus M. <mic...@on...>]

Pito.

> dict_appl.inc ...

This is my experience.

a) For a well defined board like butterfly and a limited project I  
put all my *.asm files in the words dictionary of its appl folder, e.g.:
   amforth-4.1/appl/avr-butterfly/words/*.asm
And dict_appl.inc includes all these *.asm files then.
So they are added on top of amforths core and options.

b) I have a project where 6 small boards of same type but with  
different assignment of tasks. Such a board has an atmega168 and 4  
triacs to switch 220V devices, 4 temperature sensor inputs, and 3  
leds. They run at different speeds (8MHz, 12Mhz, 20Mhz) for  
historical reasons. Some are older, some where added later.
This zoo got messed up while I was developing it the a) way.

So now I try this order:

- changes in amforth core which are the same for all devices stay in
    amforth-x.x/core/words
    They are included by amforth.asm as usual.

- Extensions of amforth used in all devices go to
    amforth-x.x/appl/<project>/words
    They are included running <project-x.asm> which includes  
amforth.asm that includes
    dict_appl.inc then, where all words of general use are included.
    So this is just the same as encouraged by the appl template in  
amforth.

- specific tasks for a device go to
    amforth-x.x/appl/<project>/<task-x>/words
    Now <project-x.asm> finaly - after having included amforth.asm -  
includes all
    specific task words by including one <task-x.inc>.
    This <task-x.inc> then includes all the words in ../<task-x>/words.

So I hope things work out now this way. :)

Michael




Am 18.09.2010 um 13:20 schrieb pito:

> Hi,
> this is a Q I'am carrying with me for a long time and therefore I
> would kindly ask you following:
> 1. there is a lot of various dict_x.inc. From time to time I have to
> add something somewhere. To be honest, I am not sure what I am
> doing, as I put required .asm simply into dict_appl.inc somewhere..
> 2. I saw some short description in the guide, but forget everything
> 3. Is there any hint or the way HOW to put everything into one BIG
> dict_big.inc, so I simple compile absolutely everything I may found
> in \core\words.. and maybe on other places? My atmega is soooo big,
> so I do not care about the space for at least 3 months..
> Thanks,
> Pito
>
>
> ---------------------------------------------------------------------- 
> --------
> Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] How TO - dict_x for bigger atmegas

[pito <pi...@vo...>]

Your text editor program works? And can do
> copy/paste?
I will investigate a little bit whether my editor knows cut and
paste..
(;-)).
So maybe I have precise my Q: 
1.Does it matter in which order I will copy all possible *.asm files
into the one include directory dict_big.inc? 
2. No dependencies at all? 
3. No special order required (except alfabetical order of words)?
4. Simple merge into one dict_big.inc as I want and do compile ?
Thanks,
P.

Re: [Amforth-devel] see

[Kalus M. <mic...@on...>]

Hi Pito.

Looks like a kind of disassembler.
So ff is subroutine threaded forth?
amforth is token threaded code (TTC).
Here we want an disforther. ;-)

Thanks for the info. Michael


Am 18.09.2010 um 10:08 schrieb pito:

> Michael,
> so I fired up ff and this is what I can see:
>
> ok<$,ram>
> see see
> 26ea eca0 f00c call  '
> 26ee eccf f00c call  cr
> 26f2 df20      rcall (see)
> 26f4 50ed
> 26f6 10ee
> 26f8 e1fc      bnz   26f2
> 26fa 50ed
> 26fc 50ed
...

Re: [Amforth-devel] How TO - dict_x for bigger atmegas

[Matthias T. <mt...@we...>]

Pito,

> Hi,
> this is a Q I'am carrying with me for a long time and therefore I
> would kindly ask you following:
> 1. there is a lot of various dict_x.inc. From time to time I have to
> add something somewhere. To be honest, I am not sure what I am
> doing, as I put required .asm simply into dict_appl.inc somewhere..

Its ok. You can include include files as well.

> 2. I saw some short description in the guide, but forget everything

Well.

> 3. Is there any hint or the way HOW to put everything into one BIG
> dict_big.inc, so I simple compile absolutely everything I may found
> in \core\words.. and maybe on other places?

well. Your text editor program works? And can do copy/paste?
Or maybe something like "copy dict_a + dict_b dict_big" (or similiar).

I dont know whether the assembler(s) understand the "include *.asm"
instruction. probably not.

Matthias

Re: [Amforth-devel] "Help" word

[pito <pi...@vo...>]

> There should be a smarter way do give help on the
> system itself..

A few years back I did as my first project on my brand new atari 520
a zif-lempel compression in 68k asm. It worked (Marcin hates this
words..)
... but this is just an another stupid idea. P. 

[Amforth-devel] How TO - dict_x for bigger atmegas

[pito <pi...@vo...>]

Hi,
this is a Q I'am carrying with me for a long time and therefore I
would kindly ask you following:
1. there is a lot of various dict_x.inc. From time to time I have to
add something somewhere. To be honest, I am not sure what I am
doing, as I put required .asm simply into dict_appl.inc somewhere..
2. I saw some short description in the guide, but forget everything
3. Is there any hint or the way HOW to put everything into one BIG
dict_big.inc, so I simple compile absolutely everything I may found
in \core\words.. and maybe on other places? My atmega is soooo big,
so I do not care about the space for at least 3 months..
Thanks,
Pito

Re: [Amforth-devel] "Help" word

[Matthias T. <mt...@we...>]

Hi,

> Matthias, YES I see now, you just updated the trunk\lib (i'm using
> tortoiseSVN under xp)!! 
> Thanks - So the next step is to start fill the help-words.frt, am I
> right?

Yes, absolutly. But I doubt that a automatically generated file
with _all_ words inside is really what we want. Its huge (a first
try gave me a 30KB file), its mostly redundant to the standard
(I dont think that standard words should be mentioned, at
least not those who are completly conforming to the standard) and
my comment headers are terribly bad.

There should be a smarter way do give help on the system itself..

Matthias

Re: [Amforth-devel] "Help" word

[pito <pi...@vo...>]

Matthias, YES I see now, you just updated the trunk\lib (i'm using
tortoiseSVN under xp)!! 
Thanks - So the next step is to start fill the help-words.frt, am I
right?
Pito.

Re: [Amforth-devel] "Help" word

[Matthias T. <mt...@we...>]

Pito,

> Hi,
> just as an inspiration - for people who use amforth with student for
> education - in the FlashForth there is a nice worh "help" I like
> (see ff36). You load the help and helpwords (~few kB) and:
> help emit

see repository: lib/help.frt and lib/help-words.frt.
the later will be automatically generated (later on)

\ small online help system

\ usage
\  help <word>
\ prints the stack effects and a short description 

\ requires words from dict_wl.inc

wordlist constant help-wl

: help
    bl word count
    help-wl search-wordlist
    if execute then
;


mt@ayla:~/projekte/Sourceforge/amforth/trunk/lib$ cat help-words.frt 

\ requires help
\ 

get-current
help-wl set-current

: emit 
  ." ( c -- ) "
  ." R:( -- ) "
  ." emits a single character on the terminal, calls pause" ;
  
: key 
  ." ( -- c ) "
  ." R: ( -- ) "
  ." waits for a key stroke, calls pause "
;


set-current


it uses a separate wordlist and if it finds a word there, it will
be executed. Not to be confused with the standard wordlists. One
should never add help-wl to the search-order ;=)

Again: great idea

Matthias

Re: [Amforth-devel] "Help" word

[Matthias T. <mt...@we...>]

Hi Pito,

> Hi,
> just as an inspiration - for people who use amforth with student for
> education - in the FlashForth there is a nice worh "help" I like
> (see ff36). You load the help and helpwords (~few kB) and:
> help emit
> emit    c --            Emit c to the serial port FIFO. FIFO is 46
> chars. Execut
> es pause.

smart idea. sound like a good target for the automatically
generated docu as well (just like the refcard and the html
pages).

> It fits to bigger atmegas.. P.

obviously ;=)

Matthias

Re: [Amforth-devel] Minicom Uploader

[Marcin C. <sa...@sa...>]

>> Erich Waelde <ew....@na...> wrote:
> Hi Al,
>
> On 09/17/2010 08:11 PM, Al Williams wrote:
>> http://dl.dropbox.com/u/360343/am4up.c
>
> superb! Works for my arduino duemilanove, which is very
> resistive to amforth-upload.py.

While we are at it, anyone has an idea why xonxoff.frt causes
serial communication to stop after ca. two lines entered?

I'd prefer to use old hardcore tools like tip or cu and software
flow control (since we can't get satisfaction w/RTS CTS or DTR).

//Marcin

[Amforth-devel] "Help" word

[pito <pi...@vo...>]

Hi,
just as an inspiration - for people who use amforth with student for
education - in the FlashForth there is a nice worh "help" I like
(see ff36). You load the help and helpwords (~few kB) and:
help emit
emit    c --            Emit c to the serial port FIFO. FIFO is 46
chars. Execut
es pause.
ok<$,ram>
help rot
rot     x1 x2 x3 -- x2 x3 x1    Rotate three top stack items
ok<$,ram>
help cmove
cmove   addr1 addr2 u --        Move u chars from addr1 to addr2
ok<$,ram>
help tuck
tuck    x1 x2 -- x2 x1 x2       Insert x2 below x1 in the stack
ok<$,ram>

It fits to bigger atmegas.. P.

Re: [Amforth-devel] Rescue Mode

[pito <pi...@vo...>]

"rescue" mode that can recover from
> corrupt EEPROM as long as the 
> basic flash portion and the bootloader flash are
> intact.

I,ve seen the images of the flash end eeprom after my some "naive
programming sessions" and there were random words written to eeprom
and flash empty space visible (as I could see only those written
between FFFFes).
Q: is the probability of corruption of the first ~60b of eeprom
space higher than of the corruption of several kB of flash code?
Pito

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Michael,
so I fired up ff and this is what I can see:

ok<$,ram>
see see
26ea eca0 f00c call  '
26ee eccf f00c call  cr
26f2 df20      rcall (see)
26f4 50ed
26f6 10ee
26f8 e1fc      bnz   26f2
26fa 50ed
26fc 50ed
26fe 0012      return
ok<$,ram>
see drop
0e4c 50ed
0e4e 50ed
0e50 0012      return
ok<$,ram>
see constant
0a64 ecda f00c call  create
0a68 d8e2      rcall cell
0a6a da9f      rcall negate
0a6c ec6c f00e call
0a70 efbd f003 goto  i,
ok<$,ram>

There is "seen" as well, so this is with "seen":
ok<$,ram>
see interpret
16f4 dff3      rcall 'source
16f6 ec6d f006 call  2!
16fa daf5      rcall false
16fc dfe8      rcall >in
16fe deeb      rcall !
1700 da1e      rcall bl
1702 deaf      rcall word
1704 dfef      rcall dup
1706 dd9b      rcall c@
1708 dd31      rcall ?0=
170a e04a      bz 17a0
170c df2b      rcall find
170e dd33      rcall d0=
1710 e033      bz 1778
1712 dc51      rcall 1+
1714 da1b      rcall state
1716 dc9a      rcall 0=
1718 dc29      rcall or
171a dd28      rcall ?0=
171c e013      bz 1744
171e a858
1720 d009      bra 1734
1722 da14      rcall state
1724 dd23      rcall ?0=
1726 e106      bnz 1734
1728 ecf5 f006 call  (s"
172c 4305
172e 4d4f
1730 3f50
1732 d0f4      bra 191c
1734 9c46
1736 ec15 f005 call  execute
173a bc46
173c d7e1      bra 1700
173e 9846
1740 9a46
1742 d7de      bra 1700
1744 9846
1746 dfce      rcall dup
1748 d86a      rcall lit
174a 104c
174c dc8f      rcall =
174e dd0e      rcall ?0=
1750 e002      bz 1756
1752 8846
1754 d008      bra 1766
1756 9a46
1758 dfc5      rcall dup
175a d861      rcall lit
175c 0ee8
175e dc86      rcall =
1760 dd05      rcall ?0=
1762 e006      bz 1770
1764 8a46
1766 d912      rcall cf,
1768 9055
176a b858
176c 8055
176e d7c8      bra 1700
1770 aa58
1772 d7f9      bra 1766
1774 dba6      rcall in,
1776 d7c4      bra 1700
1778 9846
177a 9a46
177c ec26 f007 call  drop
1780 df51      rcall number?
1782 dcf4      rcall ?0=
1784 e006      bz 1792
1786 d9e2      rcall state
1788 dcf1      rcall ?0=
178a e0ba      bz 1700
178c ec35 f002 call  literal
1790 d7b7      bra 1700
1792 d851      rcall dp>
1794 de8e      rcall c@+
1796 ecea f006 call  type
179a daa5      rcall false
179c d8b1      rcall ?abort?
179e d7b0      bra 1700
17a0 ef26 f007 goto  drop
ok<$,ram>

Pito

Re: [Amforth-devel] Minicom Uploader

[Matthias T. <mt...@we...>]

Al,

> I don't know how to turn word wrap on in the minirc.amforth file which is why 
> you need the -w flag (or ^AW when running). Anyone know how to turn that on in 
> the config file?

not really the config file but an environment variable

export MINICOM=-wC

(this part of by .profile)

Matthias

Re: [Amforth-devel] marker.asm for 4.1

[Al W. <al....@aw...>]

Haven't yet. I need to do a clean VM because I have production AVR code on 
this machine so I don't want to tamper with the assembler here. But I will.

Speaking of fun. My most recent Forth project previous to this one was a Forth 
compiler for my custom CPU done in an FPGA.

http://www.drdobbs.com/architecture-and-design/222000477

The CPU:
http://www.drdobbs.com/embedded-systems/221800122

and the Assembler:
http://www.drdobbs.com/embedded-
systems/222600279?queryText=Assembler+universal


On Saturday, September 18, 2010 02:37:48 am Marcin Cieslak wrote:
> >> Al Williams <al....@aw...> wrote:
> > Hand compile of marker from the ANS library. Note that this requires the
> > head version of 4.1 as discussed earlier.
> > 
> > http://dl.dropbox.com/u/360343/marker.asm
> 
> I think we should have a motto:
> 
> "Amforth - your computer is fun again"
> 
> :)
> 
> By the way, did you have a chance to test if avra works with my patches
> for you?
> 
> //Marcin
> 
> 
> ---------------------------------------------------------------------------
> --- Start uncovering the many advantages of virtual appliances
> and start using them to simplify application deployment and
> accelerate your shift to cloud computing.
> http://p.sf.net/sfu/novell-sfdev2dev
> _______________________________________________
> Amforth-devel mailing list
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth-devel] marker.asm for 4.1

[Marcin C. <sa...@sa...>]

>> Al Williams <al....@aw...> wrote:
> Hand compile of marker from the ANS library. Note that this requires the head 
> version of 4.1 as discussed earlier.
>
> http://dl.dropbox.com/u/360343/marker.asm

I think we should have a motto:

"Amforth - your computer is fun again"

:)

By the way, did you have a chance to test if avra works with my patches
for you?

//Marcin

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Micheal, thanks!
> So replace here with dp if you use amforth-4.1
> please.
and update words definition on the amforths web as well..

> This flashforth SEE is interesting, but I cannot
> run it, no pic here.
> What is its output?
YES the ff is interesting, indeed. Maybe sharing ideas between them
might create synergies which will give both of them a bigger
momentum, ufff..
I will fire up my pic dev board, maybe there is ff flashed in it.
There is also "seen" in the folder. As I can remeber it does
dissassembling of a word, but I will check. I did play with ff
before I had found amforth. As ff is concerned, I am desperately
waiting on dspic33/24 port (promised this autumn).. a killer
combination...
> Its a nice study of a forth system if you make a
> SEE for it :-)
currently as the forth language is concerned I can say only "Ich bin
Berliner ein swap", so frankly, this wold be for me a too big sip..
But this capability is native to amforth as amforth is doing it
billion times per day.. So just to reverse it, somehow..
Pito

[Amforth-devel] marker.asm for 4.1

[Al W. <al....@aw...>]

Hand compile of marker from the ANS library. Note that this requires the head 
version of 4.1 as discussed earlier.

http://dl.dropbox.com/u/360343/marker.asm

[Amforth-devel] Rescue Mode

[Al W. <al....@aw...>]

Thanks to some help from people on the list, I have what seems to be a pretty 
interesting "rescue" mode that can recover from corrupt EEPROM as long as the 
basic flash portion and the bootloader flash are intact.

My development boards all have a MAX232 or a USB dongle attached so I assume 
that the RX pin will be high when we start up at least some of the time. If I 
isolate the RX pin and ground it on restart, I reload a pure copy of the 
EEPROM stuff that is built into the high part of flash.

This is on the 4.1 trunk

Here's inside my main file:
;;  enable Rescue mode
;;  These settings use the RS232 in port
.equ RESCUE_PIN = PIND
.equ RESCUE_PIN_NUM = 0
.equ RESCUE_PIN_SENSE = 0
;; .equ RESCUE_PULLUP = 1 

###

Next, are changes in amforth.asm:
    ; allocate space for User Area
    .set here = here + SYSUSERSIZE + APPUSERSIZE
; NEW CODE HERE
.ifdef RESCUE_PULLUP
.if RESCUE_PULLUP
	sbi RESCUE_PIN+1,RESCUE_PIN_NUM
.endif
.endif
.ifdef RESCUE_PIN
	clr temp1   		; 256 cycles of rescue sense or no rescue
rescue_check:
.ifndef RESCUE_PIN_SENSE
.equ RESCUE_PIN_SENSE = 0
.endif
.if RESCUE_PIN_SENSE == 0	
	sbic RESCUE_PIN,RESCUE_PIN_NUM
.else
	sbis RESCUE_PIN,RESCUE_PIN_NUM
.endif
	rjmp rescue_no
	dec temp1
	brne rescue_check
	ldi XL, low(PFA_RESCUE)
	ldi XH, high(PFA_RESCUE)
	jmp_ DO_NEXT
rescue_no:	
.endif	
; END OF NEW CODE
    ; load Forth IP with starting word
    ldi XL, low(PFA_COLD)
    ldi XH, high(PFA_COLD)
    ; its a far jump...
    jmp_ DO_NEXT

#### 
Then again at the end of asmforth:
; 1st free address in EEPROM.
edp:
.cseg
; NEW CODE FROM HERE DOWN TO END
.ifdef NEED_RESCUE_DATA		
RESCUE_DATA:
    .dw XT_APPLTURNKEY
    .dw UBRR_VAL
    .dw XT_DO_ISTORE 
    .dw lowflashlast ; DP
    .dw here         ; HERE
    .dw edp          ; EDP
    .dw VE_ENVHEAD   ; environmental queries
    .dw EE_FORTHWORDLIST; forth-wordlist
    .dw EE_FORTHWORDLIST
    .dw VE_HEAD      ; pre-defined (compiled in) wordlist
    .dw EE_FORTHWORDLIST      ; get/set-order
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1
    .dw -1 ; NUMWORDLISTS + 1 entry, this entry has to be -1
.set RESCUE_DATA_END = pc
.endif

#####

I have a new file: core/words/rescue.asm:
	;;  rescue logic - Williams
VE_RESCUE:
	.dw $ff07
	.db "_rescue"
	.dw VE_HEAD
	.set VE_HEAD = VE_RESCUE
	;; : _rescue baseadd size 0  do dup i + i@ i 2* e! loop drop ;
XT_RESCUE:
	.dw DO_COLON
PFA_RESCUE:
	.dw XT_DOLITERAL
	.dw RESCUE_DATA
	.dw XT_DOLITERAL
	.dw RESCUE_DATA_END-RESCUE_DATA
	.dw XT_ZERO
	.dw XT_DODO
	.dw PFA_RESCUE2
PFA_RESCUE1:	
	.dw XT_DUP
	.dw XT_I
	.dw XT_PLUS
	.dw XT_IFETCH
	.dw XT_I
	.dw XT_2STAR
	.dw XT_ESTORE
	.dw XT_DOLOOP
	.dw PFA_RESCUE1
PFA_RESCUE2:	
	.dw XT_DROP
	.dw XT_COLD
	.dw XT_EXIT   		; never reached?
.set NEED_RESCUE_DATA = 1

###

Then in dict_appl_core.inc I simply add in words/rescue.asm. That way the 
saved state and the _rescue word is in the bootloader area which can be 
locked. Of course, would be good to move the reset vector up there too and get 
all the code up in protected flash. Might do that yet.

Obvioiusly you can set the rescue pin to whatever you want, active high or 
low, and with or without pull up (default is low and no pull up). When the 
boot process sees an active rescue pin you lose everything back to the initial 
load.

This seems to work. You can put some words in and reboot all you like with no 
problems. Then if you ground the rescue pin, you lose your custom words. In 
addition I got one lock up crash and recovered from it. 

I'd be interested to hear any success or failures. Also, I'm really new at 
digging into amforth's internals so any suggestions on making this better are 
welcome too.

Re: [Amforth-devel] see

[Kalus M. <mic...@on...>]

Am 18.09.2010 um 01:05 schrieb pito:

> Hi Michael,
> few Q (sorry, I am an forth language illiterate):
> a) how the "here" knows what to deliver - next free address of flash
> or next free address from ram?

Oh, I'm sorry. Its in amforth-3.6.

amforth-3.6
here == next free address of flash
heap == next free address from ram

amforth-4.1 (ANS forth standard)
dp   == next free address of flash
here == next free address from ram

So replace here with dp if you use amforth-4.1 please.


> b) I saw see in flashforth and I did run it - it is very short, can
> that be ported to amforth (see ff36 folder) somehow?

This flashforth SEE is interesting, but I cannot run it, no pic here.
What is its output?


> c) would it be possible to modify the routine so that we may see a
> linked list of words from which the word under investigstion has
> been compiled?, e.g.:
> see d.
> : 0 d.r space exit ok
>>
> I think there is all the information available in flash (at least
> "words" shows a lot of words, maybe there are some hidden as well so
> the name can be extracted).
> Thanks Pito

Yes.

The code field holds all the xt of the words beeing used in the  
definition.
The main principle is to use xt>nfa on them to find their names and  
type them.
Then handle loops and conditional branching as well as literals and  
strings, and maybe disassemble inlined code.

Its a nice study of a forth system if you make a SEE for it :-)

Michael

Re: [Amforth-devel] see

[pito <pi...@vo...>]

Hi Michael,
few Q (sorry, I am an forth language illiterate):
a) how the "here" knows what to deliver - next free address of flash
or next free address from ram?
b) I saw see in flashforth and I did run it - it is very short, can
that be ported to amforth (see ff36 folder) somehow?
c) would it be possible to modify the routine so that we may see a
linked list of words from which the word under investigstion has
been compiled?, e.g.:
see d.  
: 0 d.r space exit ok
>
I think there is all the information available in flash (at least
"words" shows a lot of words, maybe there are some hidden as well so
the name can be extracted).
Thanks Pito

[Amforth-devel] see

[Kalus M. <mic...@on...>]

Hi.

If you like to see what has been compiled, gforth has comfortable
  SEE <word>
as a command. There is no see in amforth so far? So this may help a  
little.

<snip>
new
hex   ( source: amforth-4.1/lib/ans94/ans.frt)
\ go from the XT backwards to get the Name field
: xt>nfa ( xt -- nfa )
     1- \ link address
     \ tricky: we look for the flash cell whose address + it content  
& 0x00ff is
     \ this address
     dup 1- >r ( -- lfa)
     begin
	1- dup ( -- fla fla )
	i@ $00ff and 1+ 2/ ( -- fla len )
	over + ( fla lfa? )
	r@ = ( fla lfa? )
     until
     r> drop  ;

\ now create a lister
: lister ( xt -- )
	xt>nfa here swap - 0 do
	cr here 1- i - dup 4 u0.r space i@ 4 u0.r
         loop ;

here .
: dummy 1122 3344 5566 ;
here .
' dummy .
' lister .

' lister lister
.s

</snip>


This is what I got:

» here .
1524  ok
» : dummy 1122 3344 5566 ;
  ok
» here .
1531  ok
» ' dummy .
1529  ok
» ' lister .
150B  ok
»
  ok
» ' lister lister

1530 1C37
152F 5566
152E 1C54
152D 3344
152C 1C54
152B 1122
152A 1C54
1529 1C0A
1528 1506
1527 0079
1526 6D6D
1525 7564
1524 FF05
1523 1C37
1522 1513
1521 1EBF
1520 0FB5
151F 0004
151E 1C54
151D 1FEB
151C 03AD
151B 0FB5
151A 0004
1519 1C54
1518 1CA5
1517 1D95
1516 1EB7
1515 1E38
1514 0121
1513 03A0
1512 1523
1511 1E92
1510 1D36
150F 1D95
150E 1CB8
150D 0121
150C 14F0
150B 1C0A
150A 14EB
1509 7265
1508 7473
1507 696C
1506 FF06 ok
» .s
  ok
»

Then I looked up cfa in the <application>.lst file:

addr cfa  mnemonic
1530 1C37 XT_EXIT
152F 5566 $5566
152E 1C54 XT_DOLITERAL
152D 3344 $3344
152C 1C54 XT_DOLITERAL
152B 1122 $1122
152A 1C54 XT_DOLITERAL
1529 1C0A DO_COLON
1528 1506 link to precedence cell of previous word
1527 0079 0 y
1526 6D6D m m
1525 7564 u d
1524 FF05 FF == precedence bits, 05 == count byte of name.

Voilà.
So we see the latest words compiled this way.
Michael