Thread: [Amforth] From frt to asm

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Hi,

Is there an automated method to compile frt to asm to skip uploading of
debugged words?

Uploading hex code from the application is what I do now. Quite ugly
IMO.

Thanks, Enoch.

Hi,

On 10/27/2012 08:06 PM, Enoch wrote:
> Is there an automated method to compile frt to asm to skip uploading of
> debugged words?

Have a look at
http://www.forth-ev.de/repos/g4/
This is a gforth program to konvert forth source code
to amforth-look-alike assembly.

Cheers,
Erich

Hi,

if you need any help with g4 just ask me.

Michael

Am 27.10.2012 um 20:13 schrieb Erich Waelde:

> Hi,
>
> On 10/27/2012 08:06 PM, Enoch wrote:
>> Is there an automated method to compile frt to asm to skip  
>> uploading of
>> debugged words?
>
> Have a look at
> http://www.forth-ev.de/repos/g4/
> This is a gforth program to konvert forth source code
> to amforth-look-alike assembly.
>
> Cheers,
> Erich
>
> ---------------------------------------------------------------------- 
> --------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to  
> resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

> From: mi-...@t-...
> Date: Sat, 27 Oct 2012 21:14:02 +0200
> To: amf...@li...
> Subject: Re: [Amforth] From frt to asm
> 
> Hi,
> 
> if you need any help with g4 just ask me.

I didn't tried (yet) it but looks nice tool to cherry pick words which work. Am I right if I say it doesn't know my own assembler words?

Maybe there should be link on amforth web page to this tool.

And if amforth-shell maintainer want to catch feature request I'd like to see this as part of it. Then it would be nice to save some words when shell would convert registers to addresses without including device.frt.

Best regards,
Hannu Vuolasaho

Hi Hannu.

Am 27.10.2012 um 21:57 schrieb Hannu Vuolasaho:
..
> Am I right if I say it doesn't know my own assembler words?

You are right.

It knows a lot of amforth words which are ANS forth.
As g4 is written in gforth adding more simple words is quite easy.
Take a look at their syntax in those examples at the end of g4 source.
And append more there.

Michael

>
> Maybe there should be link on amforth web page to this tool.
>
> And if amforth-shell maintainer want to catch feature request I'd  
> like to see this as part of it. Then it would be nice to save some  
> words when shell would convert registers to addresses without  
> including device.frt.
>
> Best regards,
> Hannu Vuolasaho
>  		 	   		
> ---------------------------------------------------------------------- 
> --------
> WINDOWS 8 is here.
> Millions of people.  Your app in 30 days.
> Visit The Windows 8 Center at Sourceforge for all your go to  
> resources.
> http://windows8center.sourceforge.net/
> join-generation-app-and-make-money-coding-fast/
> _______________________________________________
> Amforth-devel mailing list for http://amforth.sf.net/
> Amf...@li...
> https://lists.sourceforge.net/lists/listinfo/amforth-devel

Hi,

Is there an automated method to compile frt to asm to skip uploading of
debugged words?

*Downloading* hex code from the application is what I do now. Quite ugly
IMO.

Thanks, Enoch.

Hi,

> *Downloading* hex code from the application is what I do now. Quite ugly
> IMO.

Whats wrong with it? It keeps the state of the controller just the
same way MARKER does and you can transfer that state to (possibly)
a lot of other controllers (of the same type).

Matthias

Hello Matthias,

I believe that downloading code from the application should be
a discouraged practice, reasons below.

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

>> *Downloading* hex code from the application is what I do now. Quite ugly
>> IMO.
>
> Whats wrong with it? It keeps the state of the controller just the
> same way MARKER does and you can transfer that state to (possibly)
> a lot of other controllers (of the same type).

1. Downloading application compiled code may inadvertently introduce
source code bugs. For example, a programmer needs to hand type some
device-init to get his source to work in the application and forgets to
add the same to the source file itself. This can go unnoticed for a long
while since the downloaded code does include this device-init.

2. Host compiled Forth code can easily be enhanced with hand written
asm.

Thanks, Enoch.

Am 27.10.2012 21:01, schrieb Enoch:
> Hello Matthias,
> 
> I believe that downloading code from the application should be
> a discouraged practice, reasons below.

I disagree.

> 
> Matthias Trute <mt...@we...> writes:
> 
>>> *Downloading* hex code from the application is what I do now. Quite ugly
>>> IMO.
>>
>> Whats wrong with it? It keeps the state of the controller just the
>> same way MARKER does and you can transfer that state to (possibly)
>> a lot of other controllers (of the same type).
> 
> 1. Downloading application compiled code may inadvertently introduce
> source code bugs. For example, a programmer needs to hand type some
> device-init to get his source to work in the application and forgets to
> add the same to the source file itself. This can go unnoticed for a long
> while since the downloaded code does include this device-init.

Sounds like you want to separate your application code (or parts of it)
from the amforth core code *and* you seem to want to combine your
application code in binary form (aka hex or asm files) with other
amforth cores or different controller types. Am I right?

If the answer is yes: no way. Moreover I don't see even chance to do
it that way.

> 2. Host compiled Forth code can easily be enhanced with hand written
> asm.

The concept of "host compiled" is more or less the opposite of what
amforth is designed for. The initial hex files are the solution
for the chicken-and-egg problem *only*.

Matthias

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

> Am 27.10.2012 21:01, schrieb Enoch:
>> Hello Matthias,
>> 
>> I believe that downloading code from the application should be
>> a discouraged practice, reasons below.
>
> I disagree.
>
>> 
>> Matthias Trute <mt...@we...> writes:
>> 
>>>> *Downloading* hex code from the application is what I do now. Quite ugly
>>>> IMO.
>>>
>>> Whats wrong with it? It keeps the state of the controller just the
>>> same way MARKER does and you can transfer that state to (possibly)
>>> a lot of other controllers (of the same type).
>> 
>> 1. Downloading application compiled code may inadvertently introduce
>> source code bugs. For example, a programmer needs to hand type some
>> device-init to get his source to work in the application and forgets to
>> add the same to the source file itself. This can go unnoticed for a long
>> while since the downloaded code does include this device-init.
>
> Sounds like you want to separate your application code (or parts of it)
> from the amforth core code *and* you seem to want to combine your
> application code in binary form (aka hex or asm files) with other
> amforth cores or different controller types. Am I right?
>
> If the answer is yes: no way. Moreover I don't see even chance to do
> it that way.

Hand typing source to the application and later downloading of the
compiled hex from the application for safe keeping reminds me of the bad
practice in the old days were people could alter instructions from the
computer front panel switches and later could save the "core memory" to
a disc file...  A recipie for losing the integrity of the source code.
Anyone here old enough to remember the mini-computer age?

Anyway, the beauty of OSS is that it can cater to any taste. I will
certainly give G4 a serious try. Already made the first step:
svn co http://www.forth-ev.de/repos/g4

:-)

Thanks, Enoch.

Thread: [Amforth] From frt to asm

amforth is an extendible interpreter on microcontrollers

amforth-devel