amforth-devel

[Amforth] Table driven CRC-8 generator/checker

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

Hello Matthias & all,

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

crc8.frt demonstrates how MARK can be used to reclaim the code space of table
generators via the persistence of data in PAD.

This CRC-8 implementation is more efficient than that of
lib/hardware/1wire-crc8.frt if messages are transmitted/recived on a
byte-by-byte basis.

Regards, Enoch.

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

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

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

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

[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

[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.

[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,

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,


> 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:

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] 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.