Hello Matthias, Matthias Trute <mtr...@web.de> 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 ------------------------------------------------------------------------------ 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 _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
