amforth-devel — Development discussion and user support

Re: [Amforth] CVARIABLE

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

Hi Enoch,

>> http://pastebin.com/fDjrjHbN
> http://pastebin.com/3sxFdZxv (for a stupid unicode issue). Sorry.

I hope I picked the right one. Thanks, applied.

Matthias

Re: [Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Enoch <ix...@ho...> writes:

> Hello Matthias,
>
> Matthias Trute <mt...@we...> writes:
>
>> Hi Enoch,
>>
>>>> : cvariable variable -1 allot ;
>>> 
>>> Implementation is not the issue -- education is (i.e., please be
>>> reminded that the AVR is an 8bit µC).
>>
>> I hope you like
>> http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html
>>
>> Matthias
>> PS: the recipe deserves more ideas ;)
>
> Testing that clever code snippet that you found --
> : uses ( flag -- )  0= IF POSTPONE \ THEN ;
> revealed that amforth-shell.py needs to be patched again (as it did not
> understand what that backslash is doing).
> Here's the patch for your perusal (including some necessary doc work):
>
> http://pastebin.com/fDjrjHbN
http://pastebin.com/3sxFdZxv (for a stupid unicode issue). Sorry.


>
> Regards, Enoch.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Re: [Amforth] Xbee with amforth

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

Hi David,

> * I have implemented an xbee driver to format xbee transmit requests
> (and AT requests) in API mode. So I basically have API mode xbee
> comms up and running.
> 
> What I want to do next is to get the forth terminal running over the
> xbee.

Erich has done something similiar with an RS485 network.

> My plan was as follows:
> 
> For output: There seems to be an option in amforth to have interrupt
> driven comms for output as well as input. I presume this would work
> by having 'emit' send characters to some buffer and then some ISR
> scans the buffer periodically and sends the contents to the uart? If
> so, could I leave 'emit' as standard, but modify the ISR to wrap the
> characters in the buffer in an xbee packet before sending? If so, is
> there any documentation on interrupt driven output, or can you point
> me to which files to look at?

In AmForth the words EMIT and EMIT? are not fixed. They are placeholders
that call other words to do the actual work (deferred words). Other
words like TYPE and CR use EMIT so if you change EMIT, TYPE will
immmediatly use the new settings. Whether you use an interrupt or a
polling approach is below this EMIT/EMIT? pair. At least for the serial
USART's. I found no real benefit by using the interrupt EMIT (see usart-
tx-isr.asm). The atmegas have a flag, that EMIT? extracts and inside
the EMIT loop I wait for this ready-flag becomes true (ANS Forth
requires that EMIT waits for successfull transmission). If its not yet
ready, the loop calls PAUSE to do some multitasking.

Files worth reading here are core/usart-tx*.asm.

> 
> For input: I was thinking I would have a new ISR to copy incoming
> characters to a buffer and scan for complete packets. When that
> happens, extract the message text from the packet and copy it in to
> the TIB. Again, any tips on how to do that, and which files to look
> in?

Basic Input is similiar in structure. The words here are KEY and KEY?.
They are deferred as well. The default words for them are in
core/usart-rx*,asm.

Since input is not predictable, one has to be careful when _not_ using
interrupts. In AmForth, the interrupt for receiving characters works
completly behind the scenes. It gets a character and places it in an
16 byte circular buffer. The USART-KEY and KEY? words check this buffer
for new data (they know, where the information is stored). I think its
possible to implement the ISR stuff in plain forth as well, but never
started this task seriously ;)

Above these basics are words like ACCEPT (uses KEY and KEY? to fill a
buffer), REFILL and SOURCE. The latter two are used from the text
interpreter to get new data and work on them. The connection between
them is in core/tib.asm. REFILL-TIB  uses ACCEPT to fill the TIB and
SOURCE points afterwards to the result. If you want to change something
here, you may want to look at the lib/core/evaluate.frt file. there the
word SOURCE is redefined to use a string as the input for the text
interpreter.


> Does any of this make sense? I have a reasonable idea of how the
> uart works, but the workings of amforth below the level of 'emit' and
> 'key' is new territory I'm afraid.

does the above makes any sense? I'm afraid it made things even worse.

The basic idea is, that amforth has a layered structure that can be
modified at every level with deferred words: EMIT/EMIT? and KEY/KEY?
are for the single characters, SOURCE/REFILL are for the text
interpreter. The connection between them is ACCEPT. And below EMIT/KEY
pairs are the words for the usart itself, in files named usart-*.asm


Matthias

Re: [Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>>> : cvariable variable -1 allot ;
>> 
>> Implementation is not the issue -- education is (i.e., please be
>> reminded that the AVR is an 8bit µC).
>
> I hope you like
> http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html
>
> Matthias
> PS: the recipe deserves more ideas ;)

Testing that clever code snippet that you found --
: uses ( flag -- )  0= IF POSTPONE \ THEN ;
revealed that amforth-shell.py needs to be patched again (as it did not
understand what that backslash is doing).
Here's the patch for your perusal (including some necessary doc work):

http://pastebin.com/fDjrjHbN

Regards, Enoch.

[Amforth] Xbee with amforth

[David W. <ins...@gm...>]

Hi all,

I'm working on a project to hook up an xbee radio to an AVR running
amforth. I'm a bit of a forth beginner, so I'm looking for a bit of advice
if anyone can help. Maybe this would be useful to other amforthers if I get
it up and running. You are welcome to the code when it's done.

What I have so far:
* A circuit with an ATmega324P (2 Uarts), with the forth terminal on uart0
and my xbee connected to uart1.
* I have implemented some serial comms for uart1. 'emit1'and 'type1' will
send characters out of uart1 and I have an ISR to get input characters and
copy them to a ring buffer.
* I have implemented an xbee driver to format xbee transmit requests (and
AT requests) in API mode.
So I basically have API mode xbee comms up and running.

What I want to do next is to get the forth terminal running over the xbee.
My plan was as follows:

For output:
There seems to be an option in amforth to have interrupt driven comms for
output as well as input. I presume this would work by having 'emit' send
characters to some buffer and then some ISR scans the buffer periodically
and sends the contents to the uart? If so, could I leave 'emit' as
standard, but modify the ISR to wrap the characters in the buffer in an
xbee packet before sending? If so, is there any documentation on interrupt
driven output, or can you point me to which files to look at?

For input:
I was thinking I would have a new ISR to copy incoming characters to a
buffer and scan for complete packets. When that happens, extract the
message text from the packet and copy it in to the TIB. Again, any tips on
how to do that, and which files to look in?

Does any of this make sense? I have a reasonable idea of how the uart
works, but the workings of amforth below the level of 'emit' and 'key' is
new territory I'm afraid.

 Many thanks,

David

Re: [Amforth] CVARIABLE

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

Hi Enoch,

>> : cvariable variable -1 allot ;
> 
> Implementation is not the issue -- education is (i.e., please be
> reminded that the AVR is an 8bit µC).

I hope you like
http://amforth.sourceforge.net/TG/recipes/RAM-Efficiency.html

Matthias
PS: the recipe deserves more ideas ;)

Re: [Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

>> How about adding a CVARIABLE word to the kernel?
>
> Why include it into the kernel? just simply define it
> yourself.
>
> : cvariable variable -1 allot ;

Implementation is not the issue -- education is (i.e., please be
reminded that the AVR is an 8bit µC).

> btw: i found this file interesting
>
> https://github.com/ayrnieu/forth-garden/blob/master/compat.f
>
> Esp the "uses" word is smart ;)

Yes, let's copy'n paste for all the AmForth-ers to see:

\ Process the rest of line only if FLAG is true.  [IF] .. [THEN] don't
\ exist everywhere, so we use this conditional comment word insted.
: uses ( flag -- )  0= IF POSTPONE \ THEN ;

It would not occur to the "normal brain" (i.e., tainted by years of
other prog languages use) to think of a comment as a programming feature.

Thanks, Regards, Enoch.

Re: [Amforth] CVARIABLE

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

Hi Enoch,

> Hello Matthias & All:
> 
> How about adding a CVARIABLE word to the kernel?

Why include it into the kernel? just simply define it
yourself.

: cvariable variable -1 allot ;


btw: i found this file interesting

https://github.com/ayrnieu/forth-garden/blob/master/compat.f

Esp the "uses" word is smart ;)

Matthias

[Amforth] CVARIABLE

[Enoch <ix...@ho...>]

Hello Matthias & All:

How about adding a CVARIABLE word to the kernel?

It is described in Forth Programmer's Handbook by Conklin & Rather as
follows:

CVARIABLE <name>  ( — )

Create a dictionary entry for name associated with one character of
data space. Typically found in smaller systems for embedded micro-
controllers and other environments where it is advantageous to allo-
cate variables only one character in size.

Thanks, Regards, Enoch.

Re: [Amforth] where to save the IP

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

Hi Mark,

> Sorry if I bored you guys. And again thanks for the help!

You told a fascinating story. Are there any pictures
of the project/results available?

Matthias

Re: [Amforth] where to save the IP

[Enoch <ix...@ho...>]

Mark Malmros <m.m...@gm...> writes:
> Sorry if I bored you guys. And again thanks for the help!

Absolutely not, Forth & Astronomy go hand in hand!

By the way, when I need a "little Linux" I choose an OpenWRT based
solution using a converted commodity router.

Catch a falling star!

Regards, Enoch.

Re: [Amforth] where to save the IP

[Mark M. <m.m...@gm...>]

Fan ... not Guru!

Thanks for the reply Mattias and Enoch.

The ZH:ZL registers worked fine and moving my index into "unused" SRAM
helped to! It works! And thanks for pointing out the push pop pair (duh!)
I'll need that reminder since I think I'll wrap this into another loop
needing an another index register.

More hardware than software oriented - Forth fits my brain (such as it is!)
I've played with a variety of embedded Forths - and also enjoyed tinkering
with FPC.  One of my favorites was Frank Sargent's pygmy Forth - and he
wrote a 3 instruction Forth for the 'HC11 that was a lot of fun (pushing op
codes into the chip with a DIY assembler!)  Delving into Python, C,
Javascript etc... I really missed a convenient Forth - then viola! Amforth.
 I am more a tinkerer than a serious programmer. Although it's fun jumping
into the avr assembly - even if I am a bit lost at times.

And Enoch - I also appreciate your response. You seem to have perceptive
instincts about my challenge.  When I started looking into this I was
really discouraged about using the SPI because of the timing issues. And
TWI is way too slow.  There are three low level Python C wrappers to the
linux spidev module - but how to configure the Raspberry Pi as a slave? I
did find some info on rebuilding the kernel module and recompiling....

I'm reviving an old project using a 755 x 242 CCD array (TC245) for an
astrograph. I need 9 clocks and pull the 12 bit ADC in as 3 nibbles - and
ADC conversion needs about 10 microseconds. So...   it gets busy.  Here's
where Amforth saved the day (together with a lot of reading on just how the
SPI system works).  Storing and fetching to the SPI while playing with a
python spi module on the Pi side helped with my understanding of the atmega
spi system (more than the docs or any posts). Imagine doing this with C.

There are two ways to accomplish my task (one is tested).  First, on the
Raspberry Pi Master side, I enlarged the allotted buffer in the py-spidev
module (and recompiled).  Since I am reading each serial register of 242 +
10 pixels in 12 bits per "pass", I store that in SRAM (504 bytes) and
"pull" it out between passes with a Python loop - testing for a null byte
between passes. Since I can quickly block the SPI register in assembly this
works well and the latency (when testing for null bytes) on the master side
is minimal - and it appears that appending the resulting python list array
is a shallow copy process! Using this approach I can transfer my 380520
bytes out of the CCD in under 1.5 seconds (this is a cooled transfer frame
array) (The 328P clocked at 20 mhz and running the Pi SPI at 3 Mhz) - which
is more than acceptable.

And there is the second way: Since I only need 12 bits but transfer in
bytes... do a bit shift and assure the LSB.  Then just stream everything
(nibbles as bit shifted bytes) to the buffer on the Pi, cull out the null
bytes and bit shift back.   If you don't put anything into the SPDR
register, it goes back to the Pi as a null byte.  And the Pi has 512 mb of
ram most of which isn't doing anything! This approach might get the readout
time under a second BUT generate "jitter" in the clock timing when checking
the SPIF flag... not sure if this is an issue for the CCD.

And to your point Enoch - the interrupts are off!

I also have Amforth talking with a Pi - just using the UART - for an
autoguider.  Using a USB webcam on the Raspberry Pi for tracking,
processing the image in Python and correcting my steppers for the
equatorial drive of the telescope. I also plan on using this system to
 mosaic the CCD images.

Sorry if I bored you guys. And again thanks for the help!

Mark


On Tue, Mar 12, 2013 at 7:14 PM, Enoch <ix...@ho...> wrote:

> Matthias Trute <mt...@we...> writes:
>
> > PS: The atmega SPI system can do the slave work too. Did you
> > check the datasheets? I've not used it myself however.
>
> Hello Mark & All,
>
> There is indeed a problem with the SPI functioning as a slave concerning
> its transmitter, if the other side master cannot guarantee a time delay
> between consecutive communication cycles. A hardware transmit buffer is
> much needed... :-(
>
> If there is no guarantee of a time delay between communication cycles
> not only you would have to go asm level you would also have to work with
> the Interrupt system disabled.
>
> As you are responsible for the master firmware as well I suggest that
> you find a way to delay successive communications on the master and on
> the AVR slave stay high level (Forth).
>
> Regards, Enoch.
>
>
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_mar
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel
>

Re: [Amforth] where to save the IP

[Enoch <ix...@ho...>]

Matthias Trute <mt...@we...> writes:

> PS: The atmega SPI system can do the slave work too. Did you
> check the datasheets? I've not used it myself however.

Hello Mark & All,

There is indeed a problem with the SPI functioning as a slave concerning
its transmitter, if the other side master cannot guarantee a time delay
between consecutive communication cycles. A hardware transmit buffer is
much needed... :-(

If there is no guarantee of a time delay between communication cycles
not only you would have to go asm level you would also have to work with
the Interrupt system disabled.

As you are responsible for the master firmware as well I suggest that
you find a way to delay successive communications on the master and on
the AVR slave stay high level (Forth).

Regards, Enoch.

Re: [Amforth] where to save the IP

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

Hi Mark,

> First of all - thanks to you and all your cohorts for Amforth!  I have been
> using Forth for 30 years (F83 ... ) for a variety of projects and Amforth
> (since 4.2) with the 328P as my current platform.

Wow. A Forth Guru. Welcome!

> A quick question: for timing purposes, I have dropped into assembly
> (driving the SPI system as a slave to a Raspberry Pi since the Pi isn't
> easy to slave! BTW, the Pi is my ISP too, fun!) I'm trashing the X register
> r26 & r27 to index into SRAM - so when I exit my code via 'JMP_ DO_NEXT'
> I'm back at the interpeter prompt (surprise!). Where... and how.. is the
> safest way to save the IP ... and what else might I be trashing? (I am
> using temp0 thru 7 (except for temp5))

There a few occasions, where I need two index registers. placing them
on the (CPU-) stack within one assembler word works fine:

push xl
push xh
... do some work with XH:XL, but no jmp DO_NEXT
pop xh
pop xl

> 
> My thinking is to use r31:r30 in place of r27:r26 .

The ZH:ZL is fine. Keep in mind that no CPU register is
guaranteed to survive the inner interpreter (aka a jmp DO_NEXT).
(the currently unused CPU registers are reserved for
future use, not that I have an actual use for them, but...).

Matthias

PS: The atmega SPI system can do the slave work too. Did you
check the datasheets? I've not used it myself however.

[Amforth] where to save the IP

[Mark M. <m.m...@gm...>]

Hi Matthias!

First of all - thanks to you and all your cohorts for Amforth!  I have been
using Forth for 30 years (F83 ... ) for a variety of projects and Amforth
(since 4.2) with the 328P as my current platform.

A quick question: for timing purposes, I have dropped into assembly
(driving the SPI system as a slave to a Raspberry Pi since the Pi isn't
easy to slave! BTW, the Pi is my ISP too, fun!) I'm trashing the X register
r26 & r27 to index into SRAM - so when I exit my code via 'JMP_ DO_NEXT'
I'm back at the interpeter prompt (surprise!). Where... and how.. is the
safest way to save the IP ... and what else might I be trashing? (I am
using temp0 thru 7 (except for temp5))

My thinking is to use r31:r30 in place of r27:r26 .

Thanks.
Mark Malmros

Re: [Amforth] dual licensensing amforth???

[Enoch <ix...@ho...>]

Hi Erich,

Erich Waelde <ew....@na...> writes:

> Well. If I'm after your dishwasher programm, I just buy a diswasher,

Since IANAL and since the copyright law in Germany is perhaps different
than that in the US, let's put this difficult issue aside for a
while.

>> Being corp. world friendly has the power to transform the Amforth
>> project...
>
> In my humble opinion not a worthwhile route to take. But that's not for
> me to decide, because I'm not the copyright holder.

Don't you want Atmel to include Amforth among their recommended design
practices? Atmel does endorse (and include) GNU's AVR-GCC and AVR-LIBC
for their permissive run-time licenses. 

To be continued, need to do some real work now :-)

Regards, Enoch.

[Amforth] dual licensensing amforth??? (was: Table driven CRC-8 generator/checker)

[Erich W. <ew....@na...>]

Hi,

On 03/09/2013 08:42 AM, Enoch wrote:
> Hi Erich&  All;
> 
> Erich Waelde<ew....@na...>  writes:
> 
>> I do not see a way to combine amforth (GPL) with a proprietary
>> application written in amforth. On the other hand, I'm of course
>> not a lawyer.
> 
> Let's assume that your customer installs generic Amforth software (asm +
> libs + your special modifications) into a proprietry AVR based system
> for dish-washer control. There is no doubt that this system is GPL as
> well (i.e., all "your special modifications" must be exposed). Now, you
> supply your customer seperatly with dish-washer application software as
> a set of Forth files to compile/upload. Knowing about GPL what I know no
> one can make a serious argument that your dish-washer application is GPL
> as well and needs to be exposed to the prying eyes of competing
> dish-washer manufacturers [who are eager to learn how you managed to
> reach such a great electric efficiency :-) ]
> 
> Still, there is some inconvenience involved in the above as we need to
> maintain an "arms length" distance between loading of the GPL stuff and
> loading of the proprietry stuff. Here Matthias, as the copyright holder,
> can step in and allow certain exceptions. For example, permit combined
> loading of hex code.

Well. If I'm after your dishwasher programm, I just buy a diswasher,
then I get a GPL system (amforth) and the source code of the application.
Inconveniently I need to upload the source myself. Mangling the source
code into a blob of asm does not help. Encrypting the mangled asm blob
does not help much either, because it must be "run" on the controller in
clear.

IANAL, but I'm not convinced at all, that your "selling" dishwasher can
be covered by the "I can use GPL software for whatever purpose for my
own use" (freedom 0) and then add a proprietary piece of code to make it
a functional dishwasher. Ok, even if you sell a "diy dishwasher assembly kit"
consisting of dishwasher, programmer, software, I'm not convinced.

It all boils down to the question, whether Amforth+YourProprietaryApplication
is a derived work or not. A Forth definition compiled in at the prompt is
indistinguishable from the same definition loaded as asm, i.e. part of 
amforth.

Maybe someone else has better arguments.

> Being corp. world friendly has the power to transform the Amforth
> project...

In my humble opinion not a worthwhile route to take. But that's not for
me to decide, because I'm not the copyright holder.


Cheers,
Erich

Re: [Amforth] Table driven CRC-8 generator/checker

[Enoch <ix...@ho...>]

Hello Matthias & All:

Matthias Trute <mt...@we...> writes:

>> What is your opinion about endorsing
>> a certain Forth style (my preference is the openfirmware style).
>
> A quick look at some source files does not reveal anything that
> should be done differently. As long as you dont use the gforth
> style.. (my impression from reading the gforth sources is that
> they love programming like this:
>
> : (foo) bar ;
> : foo (foo) baz ;
>
> ((foo) is never used (or even documented) elsewhere)
>
> I admire the work of the gforth people, but wrt code
> readability I try to beat them.
>
> Would you mind to write a few sentences what you suggest for a recipe?
>

I found the description of the open firmware style (and confirmed that
against their repo :-) in "Forth Programmer’s Handbook" by Forth Inc.,
section 8.2, pages 213-217. This is not their print edition but the PDF
version included in <http://www.forth.com/swiftforth/dl.html>.

Regards, Enoch.

Re: [Amforth] Table driven CRC-8 generator/checker

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

Hi Enoch,


> Let's revisit the issue of Amforth relationship with proprietary designs
> at a later time.

You seem to hope for something ;)

> If you strongly feel that all contributed code should be GPL licensed I
> can live with that. I will send a correction to your web.de address.

Great, thank you indeed.

> I plan further code contributions.

Even greater. You will be my hero ;)

> What is your opinion about endorsing
> a certain Forth style (my preference is the openfirmware style).

A quick look at some source files does not reveal anything that
should be done differently. As long as you dont use the gforth
style.. (my impression from reading the gforth sources is that
they love programming like this:

: (foo) bar ;
: foo (foo) baz ;

((foo) is never used (or even documented) elsewhere)

I admire the work of the gforth people, but wrt code
readability I try to beat them.

Would you mind to write a few sentences what you suggest for a recipe?

> Now
> that we have a project specific configuration file (appl_defs.frt), how
> about recommending all contributors to respond to, say, something akin to
> python __debug__ constant which determines the extent of run-time tests.

That would be fine, but will create objections from people that even
do not like the amforth-shell for its python-ness ;)

Matthias

Re: [Amforth] Table driven CRC-8 generator/checker

[Enoch <ix...@ho...>]

Hello Matthias & All,

Let's revisit the issue of Amforth relationship with proprietary designs
at a later time. As for my CRC-8 code contribution...

Matthias Trute <mt...@we...> writes:
>> According to <http://en.wikipedia.org/wiki/MIT_License>: "The license is
>> also GPL-compatible, meaning that the GPL permits combination and
>> redistribution with software that uses the MIT License".
>
> Live (esp my) will be much easier when no legal battles are fought.
> Keep things small and simple. Maintaining two different licenses
> in one package is everything but simple or small.

If you strongly feel that all contributed code should be GPL licensed I
can live with that. I will send a correction to your web.de address.

I plan further code contributions. What is your opinion about endorsing
a certain Forth style (my preference is the openfirmware style). Now
that we have a project specific configuration file (appl_defs.frt), how
about recommending all contributors to respond to, say, something akin to
python __debug__ constant which determines the extent of run-time tests.

Regards, Enoch.

Re: [Amforth] Table driven CRC-8 generator/checker

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

Hi Enoch,

> According to <http://en.wikipedia.org/wiki/MIT_License>: "The license is
> also GPL-compatible, meaning that the GPL permits combination and
> redistribution with software that uses the MIT License".

Live (esp my) will be much easier when no legal battles are fought.
Keep things small and simple. Maintaining two different licenses
in one package is everything but simple or small.

> By the way, I recommend that thought is given to encourage Amforth use
> in commercial (proprietary) designs. This is important if you wish to
> draw in professional developers (for their skills and opening up
> financial support opportunities).

Here comes another simpleness: How transfer the money (to whom? A
company I have to run, me myself,...), I'd have to manage that in an
international context (taxes, customs, export regulations, you get the
picture). No, thanks. My currency is much simpler (and probably more
costly for the donor, I know): Lines Of Code and/or (public!)
publications on what you did with amforth and how. The GPL helps here
a lot. If someone wants to use forth in an closed environment, go ahead.
Forth Inc and MPE will happily sell the tools and the support.
And they will not tell everyone who uses them and for what.
AmForth is pretty close to standard forth, so I'd say the porting should
be easy. (I'm honored that you declined them in favor for
amforth. Really.)

> As you recall my first attempt to patch the shell was quick yet too
> "dirty" (direct incorporation of Python dictionary, yuk :-). This local
> appl_defs.frt is cleaner. It's not just code saving that I am after. I
> want to keep WORDS shorter.

I've committed your patch to the code base. I'm not that happy with
it, but have not yet a better solution. Think of it as the starting
point to make the shell more adaptable to local project settings (which
is a good goal).

> I want to encourage future library
> submissions to be configurable (*).

The GPL makes things clearer here as well. You'll _have to_ publish
your code. And if your dish washer competitor uses it to make a
better product, well fine. You can use his code as well. A huge
example how this can work is the linux world.

> (*) and here I need to highlight again the need for bracketed
> conditionals.

;)

Matthias
PS: I've seen the other mails, so see this mail as an combined answer.

Re: [Amforth] Table driven CRC-8 generator/checker

[Enoch <ix...@ho...>]

Hi Erich & All;

Erich Waelde <ew....@na...> writes:

> I do not see a way to combine amforth (GPL) with a proprietary
> application written in amforth. On the other hand, I'm of course
> not a lawyer.

Let's assume that your customer installs generic Amforth software (asm +
libs + your special modifications) into a proprietry AVR based system
for dish-washer control. There is no doubt that this system is GPL as
well (i.e., all "your special modifications" must be exposed). Now, you
supply your customer seperatly with dish-washer application software as
a set of Forth files to compile/upload. Knowing about GPL what I know no
one can make a serious argument that your dish-washer application is GPL
as well and needs to be exposed to the prying eyes of competing
dish-washer manufacturers [who are eager to learn how you managed to
reach such a great electric efficiency :-) ]

Still, there is some inconvenience involved in the above as we need to
maintain an "arms length" distance between loading of the GPL stuff and
loading of the proprietry stuff. Here Matthias, as the copyright holder,
can step in and allow certain exceptions. For example, permit combined
loading of hex code.

Being corp. world friendly has the power to transform the Amforth
project... 

Regards, Enoch.

Re: [Amforth] Table driven CRC-8 generator/checker

[Erich W. <ew....@na...>]

Hi Enoch,


> By the way, I recommend that thought is given to encourage Amforth use
> in commercial (proprietary) designs. This is important if you wish to
> draw in professional developers (for their skills and opening up
> financial support opportunities).
>
> Even as things stand there is a way to "marry" GPL with proprietary code
> which is described here:
> <http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem>.
> The basic idea is:
>
> "However, in many cases you can distribute the GPL-covered software
> alongside your proprietary system. To do this validly, you must make
> sure that the free and non-free programs communicate at arms length,
> that they are not combined in a way that would make them effectively a
> single program."

"Alongside" is the important term here.

As far as I understood, building a Forth application means that
you always extent the original Forth system. This is, as far as
I know, a "derived work". In contrast to a compiled system,
where you can replace one compiler with another and one "libc"
with another and still have a working system, this doesn't work
with Forths. The words of you application and amforth form a
single programm.

I do not see a way to combine amforth (GPL) with a proprietary
application written in amforth. On the other hand, I'm of course
not a lawyer.

> Still, as the copyright holder you have the power to modify the license
> to facilitate certain Amforth usage. I will expand if you are
> interested.


Erich

Re: [Amforth] Table driven CRC-8 generator/checker

[Enoch <ix...@ho...>]

Hello Matthias,

Matthias Trute <mt...@we...> writes:

> Hi Enoch,
>
>
>> Please find in <http://pastebin.com/BRHaitj9> my complete CRC-8 implementation
>> for peer review and library inclusion if there is interest.
>
> Since you put your code under MIT license, there is AFAIK
> no legal way to combine it with amforth (GPL). IANAL && IMHO.

According to <http://en.wikipedia.org/wiki/MIT_License>: "The license is
also GPL-compatible, meaning that the GPL permits combination and
redistribution with software that uses the MIT License".

Broadcom Corp. chose MIT License when contributing crc8.c/crc8.h to the
Linux kernel. I was simply following their example :-)

*Still*, if you feel strongly that anything incorporated into the
Amforth system must be released under GPLv2 I will respect your
decision!

By the way, I recommend that thought is given to encourage Amforth use
in commercial (proprietary) designs. This is important if you wish to
draw in professional developers (for their skills and opening up
financial support opportunities).

Even as things stand there is a way to "marry" GPL with proprietary code
which is described here:
<http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem>.
The basic idea is:

"However, in many cases you can distribute the GPL-covered software
alongside your proprietary system. To do this validly, you must make
sure that the free and non-free programs communicate at arms length,
that they are not combined in a way that would make them effectively a
single program."

Still, as the copyright holder you have the power to modify the license
to facilitate certain Amforth usage. I will expand if you are
interested.

>> PS1: Is there any reference implementation for [if] [else] [then]. I need them
>> and would be ready to help if needed.
>
> The file included was the reference implementation. I have no plans
> to implement these words in the near future (had no use for them for
> years).

Hmm... giving up on something useful as this one:
[undefined] rdrop  [if]  : rdrop  r> drop  ;  [then]
 
You wouldn't turn down a helping hand, would you? :-)

>> PS2: I assumed that my amforth-shell.py patch was accepted :-)
>
> I hope, Keith would comment on it as well. Another strategy for
> the constants would be to read the files twice. The first pass
> extracts the constant definitions and the second pass uses
> them. If the replacement really saves code space (every literal
> uses 2 cells in the dictionary).

As you recall my first attempt to patch the shell was quick yet too
"dirty" (direct incorporation of Python dictionary, yuk :-). This local
appl_defs.frt is cleaner. It's not just code saving that I am after. I
want to keep WORDS shorter. I want to encourage future library
submissions to be configurable (*).

Regards, Enoch.

(*) and here I need to highlight again the need for bracketed
conditionals.

Re: [Amforth] Table driven CRC-8 generator/checker

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

Hi Enoch,


> Please find in <http://pastebin.com/BRHaitj9> my complete CRC-8 implementation
> for peer review and library inclusion if there is interest.

Since you put your code under MIT license, there is AFAIK
no legal way to combine it with amforth (GPL). IANAL && IMHO.

> PS1: Is there any reference implementation for [if] [else] [then]. I need them
> and would be ready to help if needed.

The file included was the reference implementation. I have no plans
to implement these words in the near future (had no use for them for
years).

> 
> PS2: I assumed that my amforth-shell.py patch was accepted :-)

I hope, Keith would comment on it as well. Another strategy for
the constants would be to read the files twice. The first pass
extracts the constant definitions and the second pass uses
them. If the replacement really saves code space (every literal
uses 2 cells in the dictionary).

Matthias