Re: [Amforth] Wish to FORGET

Matthias Trute writes: > PPS: I'm not fully and finally against FORGET, I simply won't implement > it. And probably never include it into amforth. Hello Matthias, That's ok for now :-) I solved the problem of removing table generators with marker, communicating their output to unaffected code

Re: [Amforth] Wish to FORGET

Hi Enoch, >> I have absolutely no problem that FORGET will be forgotten. > > Here's an interesting article by one of Forth greats: > "Proposal: un-obsolete FORGET" > http://www.forth200x.org/unobsolete-forget.txt > > The author sees FORGET as a useful tool for hot system upgrade. Compare FIND w

Re: [Amforth] Wish to FORGET

Hello Matthias, Matthias Trute writes: > Hi, > >> Indeed, your suggested use of MARKER is what I anticipated but I have to >> agree with you, it would be too difficult/dangerous for an average >> programmer to try. > > I wrote "difficult" not "too difficult" A subtle difference. > >> Hence, let

Re: [Amforth] Wish to FORGET

Erich Waelde writes: > Hi Enoch, > > On 03/04/2013 04:03 AM, Enoch wrote: > >> The code at will expire in 4 weeks. > > See? In 4 weeks the code is gone. If you had added it to the message > in the first place, then anyone could find it even in years, if > the mail a

Re: [Amforth] Wish to FORGET

Hi Enoch, On 03/04/2013 04:03 AM, Enoch wrote: > The code at will expire in 4 weeks. See? In 4 weeks the code is gone. If you had added it to the message in the first place, then anyone could find it even in years, if the mail archive is still available on the net

Re: [Amforth] Wish to FORGET

Matthias Trute writes: > Hi, > >> Indeed, your suggested use of MARKER is what I anticipated but I have to >> agree with you, it would be too difficult/dangerous for an average >> programmer to try. > > I wrote "difficult" not "too difficult" A subtle difference. > >> Hence, let us revisit FORGET

Re: [Amforth] Wish to FORGET

Hi, > Indeed, your suggested use of MARKER is what I anticipated but I have to > agree with you, it would be too difficult/dangerous for an average > programmer to try. I wrote "difficult" not "too difficult" A subtle difference. > Hence, let us revisit FORGET. > I agree with you again that with

Re: [Amforth] Wish to FORGET

Hello Matthias, Matthias Trute writes: > Hi Enoch, > > >> How can I reclaim the Flash memory of the crc8_msb_table word itself? >> >> (1) Our Tools Ext don't include FORGET. >> >> (2) I could use Core Ext MARKER if we had a deferred facility of >> sort. I.e., create a deferred table and fill i

Re: [Amforth] Wish to FORGET

Hi Erich, While my CRC-8 code may be of interest I did not want it to become the focus of conversation and this is why I posted the code as a "pastebin". My focus was on Forth ability to modify the program structure during program execution and indeed Matthias has addressed this very topic. I int

Re: [Amforth] Wish to FORGET

Enoch, On 03/03/2013 05:22 AM, Enoch wrote: > I wrote a table driven CRC-8 routine for short messages using any > generating polynomial, seehttp://pastebin.com/1YtVdMeg > (I didn't like the slow approach of lib/hardware/1wire-crc8.frt). If you want me to look at your code, you better include it i

Re: [Amforth] Wish to FORGET

Hi Enoch, > How can I reclaim the Flash memory of the crc8_msb_table word itself? > > (1) Our Tools Ext don't include FORGET. > > (2) I could use Core Ext MARKER if we had a deferred facility of > sort. I.e., create a deferred table and fill it using a transient > crc8_msb_table (which MARKER w

[Amforth] Wish to FORGET

Hello Matthias & all, Here's something beyond me in Amforth, please help: I wrote a table driven CRC-8 routine for short messages using any generating polynomial, see http://pastebin.com/1YtVdMeg (I didn't like the slow approach of lib/hardware/1wire-crc8.frt). The Flash look-up table, crc8tab,