Re: [Amforth] amforth-shell.py idea

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

Am 13.10.2012 22:51, schrieb Enoch:
> On 10/13/2012 02:53 PM, Matthias Trute wrote:
>> Hi,
>>
>>> We do still have a problem how to deal with hardware idiosyncrasies as
>>> timer0.frt demonstrates. It should not be dealt with through the shell
>>> (re my ill thought #py idea).
>>>
>>> The generic frt code should include some preprocessing instructions to
>>> produce MCU specific code, m4 perhaps?
>>
>> A preprocessor would create a similiar dependency on
>> additional tools that (at least) Erich dislikes.
>>
>> m4 (or cpp) are tools for the unix people, but the
>> majority of the amforth users use windows (for whatever
>> reason....)
> 
> Because Atmel provides a great IDE for Windows free of charge :-)
> 
>>
>>> Once you decide on the standard people would follow :-)
>>
>> Hell, no! I wont make decisions for you ;)
>>
>> maybe a preprocessor in (g)forth can help us?
> 
> 
> I think that any Amforth pre-processing code should syntactically look
> very different from the surrounding Amforth code. Mixing Gforth with
> Amforth may lead to confusion where the code actually executes.
> 
> All Unix tools are easily available now in windows. We just need to
> decide which tool is most suitable for adapting a generic Forth library
> code for a particular AVR MCU. I see this tool utilized at Amforth
> install stage. Perhaps it would unify those appl/ projects...

The easiest way would an implementation of [if] and friends
...
\ older mcu's may need
[undefined] TCCR0B [if] TCCR0 constant TCCR0B [then]
[undefined] TIMSK0 [if] TIMSK constant TIMSK0 [then]
....

That would not even require any external tool at all

Volunteers welcome ;) (be aware: its not that easy
as its seems to be). I just added
http://amforth.svn.sourceforge.net/viewvc/amforth/trunk/lib/ans94/tools/bracket-conditional.frt?view=log
it does not work in interactive mode however.

Matthias