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. >> 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 and implementation in one document. The code in the lib/ directory is not that well documented. 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 _______________________________________________ Amforth-devel mailing list for http://amforth.sf.net/ Amforth-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/amforth-devel
