My idea of badnop is to have the compiler and feel of the system relatively architecture-free, but still enable the target languages to be very architecture dependant and 'close to the metal'. However, if a processor is complex enough to support an efficient C compiler, or even better to support a unix which can host its own C compiler, there is little use of the very low-level approach in brood. It's probably better to target a subset of C, or even a virtual machine written in C or generated C. This is what POKE and PF2 are about. Therefore, i'm limiting the possible targets to very simple chips. This reduced generality should enable a bit of simplification here and there.. One remark though: PIC18 doesn't support any addressing modes: they are all encoded using virtual registers. dsPIC30 does have addressing modes, so that's probably a drive for the assembler to change a bit. --- Arch: PIC18 Status: implemented this is the central 8 bit architecture, with a fairly optimal peephole optimizer. the chip has just the right complexity for an efficient implementation of a stack machine. optimizer is reasonably simple, and consists of mostly DUP/DROP elimination and literal folding, plus some macros abstracting machine idioms such as bit test instructions. Arch: DSPIC30 Status: next physical platform, first 16bit platform together with the other PIC 16bit data path cores, this seems like a very interesting chip to use as the first 16bit chip. available in small DIP packages, ideal for small hacks, and close enough to the PIC18 architecture to do the compiler generalization incrementally. Arch: ARM7TDMI Status: probably the first physical 32bit platform seems to be the de facto standard for 32 bit microcontrollers. these are a bit faster than the 16bit microchip cores, and have the advantage of a 32bit data path. however, the thumb mode behaves more like a 16bit core. cost about the same as 16bit arch. there are already a lot of forth implementations for these. this is on my wish list too, though currently postponed because i can only get access to them as 70 euro modules, not in standalone DIP packages, means i need to aquire some soldering skills first :) Arch: POKE Status: first logical 32bit platform (C) The portable POKE VM based on a call threaded VM with EXIT bit. This is to be the core of Packet Forth, a linear OO stack language. Arch: PIC10F/PIC12F/PIC16F Status: maybe the previous version of badnop supported the 12F/16F chips. i never programmed a 10F, which is probably too small to support a forth. these chips are not self-programming, so the devellopement cycle is a bit more painful, requiring reboots. an interesting exercise for this architecture is to write a virtual machine that uses the eeprom memory as a huffmann encoded store. Arch: AVR Status: maybe availability of DIP packages, liberal sample policy, and availability of an expert friend were the key reasons to choose PIC over the seemingly more popular AVR. however, the popularity of the Arduino board might eventually tick me over.. for a very good PIC/AVR comparison, see: http://www.electricstuff.co.uk/picvsavr.html note a lot of the issues mike addresses are solved in the 18f series. Arch: 68K Status: maybe since you can find these in a lot of old palm OS devices, and those are easy to find, and 68K is just about everywhere else, it might be an interesting target for recycling purposes. the SCF5250 DSC seems a nice target too. Arch: Z80 only out of curiosity. and because i have an MSX.