Re: [Amforth] Useful?

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

Hello Matthias,

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

> Hi Enoch,
>
>> Well, let's try the following indirect argument:
>> 
>> Atmel thought these instructions to be important enough to "spend" 2^10
>> opcodes out of their precious 2^16 RISC range. Don't we need to respect
>> that engineering decision by suitable Amforth words?
>
> No, we don't. Sounds too harsh? Well, yes. Atmel did a lot of
> at least strange design decisions, that later (for the atxmega
> line) got changed. The IO area with 32 possible addresses was
> fine for the very first controllers, but became later a real
> bottleneck.

Personally, if my Flash memory requirements would go beyond 128KB (64KW)
I will choose a different µC architecture. 

>
>>> As Matthias pointed out elsewhere: your snippet is intersting,
>>> because assembly instructions are coded in at compile time
>>> without loading the full assembler. That I can see.
>> 
>> Yes, that DIY assembly approach can do things which lib/assembler.frt
>> may find difficult to follow :-)
>
> Your SBI/CBI macros are an excellent and inspiring solution for a
> particular problem. I think it really deserves to be published.
> As a recipe in the cookbook. There are quite a few solutions, that
> do not go into the repository and are worth studying. I do hope,
> you can live with that. It has the advantage to have documentation

I can certainly live with that :-) You are, as long as your contribution
stream is sustained, the "Guido van Rossum" of this project. I state
that as a fact, with true appreciation to your contribution.

My sense of programming aesthetics requires critical sections to be as
short as possible if not eliminated altogether. It's a result of a
seminar I took years ago on programming cooperating processes, based on
an E.W.Dijkstra paper.

In my current project Atmel has even given me a GPIOR0 (a general
purpose register) that I can apply SBI/CBI atomically to. Why should I
give it up?

> and implementation in one document. The code in the lib/ directory
> is not that well documented.

IMHO the asm code needs better docuemntation as a proirity as well. Your
move to reST makes it easier to contribute. I consider it a personal
obligation to help and hope that other Amforth users feel the same.

Keep up the good work!

Regards, Enoch.

>
> Matthias
>
>
> ------------------------------------------------------------------------------
> 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_feb