The current BADNOP version can be found in the [[darcs/badnop|darcs archive]]. To check out do ~~~ darcs get --partial http://zwizwa.be/darcs/badnop~~~ BADNOP is a layered Forth system for writing microcontroller forths. It consists of a 32 bit Forth [[darcs/badnop/src/badnop.c|kernel]] written in C. The [[darcs/badnop/host|crosscompiler]] is written in Forth, and tries to provide an interactive interpreter/compiler for microcontrollers with a Harvard Architecture. BADNOP is not ANS Forth compatible, since this would require a hardware abstraction layer, which misses the point. Its most distinguishing characteristic is a 2x3=6 mode interpreter: x . The 'host' mode is the 32 bit Forth running on the host system, the 'target' mode is the for target code compilation and interactive remote execution, and the 'macro' mode is a convenience mode to provide an almost equal syntax for nested words (procedure calls) and inlined words. More complicated macros can be written in host mode, which effectively implements the target language. There is only 1 dictionary. Word semantics depend on the last character of input/dictionary words and wether the word points to host or target code. Included in the distribution are 2 Forths for the [[darcs/badnop/stc16|16bit]] / [[darcs/badnop/stc14|14bit]] code and 8 bit data Microchip PIC family. The first is fairly complete, compiles to native PIC code, and is fully interactive since the 16bit cores can write to the flash program memory. The second one is a bit more limited due to lack of this feature in the 14bit cores. wiki/ZwikizwakiPages/BootStrapping Been thinking a lot about this lately... The thorn in my eye is that PacketForth contains too much very boring C code. This could be generated from forth easily, toward a cleaner system. In turn this would allow to write the parser, interpreter and type system in forth. Making the packet system true OO, so you can add new types in forth too. Basicly what i want is to build some tower of complexity: 0 machine code (C) 1 minimal forth 2 array/grid processing (A/V) 3 dynamic memory and type/object system (polymorphy) + reference count garbage collection (packets) 4 symbolic code and mark/sweep garbage collection (lisp) The last one is beyond what there is now. The idea is that any level can feed back to a level below. The need for this layered approach is rooted in * Distributed nature of the hardware (microcontrollers) * Considerations about efficiency (video, audio, CA, ... engines) * Using a single, multiple target optimizing compiler is problematic. * Availability of a high-level (scheme like) component increases flexibility. Writing a component should be done in the highest possible level. If it's not sufficiently fast or small, it should be compiled to a lower level. Now, how do you bootstrap this? The traditional approach is to bootstrap the low level system, and bootstrap up in stages. So what about starting at the very top? If the system can compile itself, there is no real reason to start bootstrapping at the bottom. It's might be easier to start building the ChickenForth first instead of starting with the EggForth. The end result for a self-supporting language will be of course the same: the lower layers supporting the upper layers. LINKS [[http://compilers.iecc.com/comparch/article/97-05-231|geenie]]wiki/ZwikizwakiPages/ChickenForth Alternative to EggForth (see BootStrapping) Instead of using only gcc to piggyback on (using it as a machine language), what about writing the top level language on top of scheme, and gradually work down toward the bottom machine layer (gcc)? This uses two external components. Gcc as bottom layer, plus an external 'arrow' from gcc to scheme. The question then is how to loose features? Which features to loose first? But most importantly, does this really make sense? Note that the idea here is not to have the 'bottom' language to support the 'top' one. This approach seems only useful for cross-compilation. But, it would be really cool to try the route. First experiments seem to indicate that implementing a Joy/Factor like language in Scheme is relatively trivial. The practical question is: in how far is it really useful to build the language on itself. PacketForth really is more of an application than a true self-supporting language. Adding self-support would be cool, and produce probably cleaner code and more understanding, but no real features, only meta-features, or proto-features :) SCHEME vs FORTH --------------- I really like scheme. Never used it to write a big program though. I want to make a forth-like language with the features of scheme. So, basically, i just want to change syntax (the feel) such that it interfaces better with forth. Time to clarify what i mean with bridging pf and scheme. This is not entirely trivial. Basically, this is the supercollider problem: a client language, garbage collected wastfulness, interacts with a server system which is relatively simple. The core idea is that data in the server cannot be directly manipulated from the client side, only the processes that manipulate the data can be influenced. This is like pd, only there the gui is rather dumb, but in theory, there's no reason it could do more elaborate things. To reflect this to pf, the scheme cannot be used to write real-time processors (RTPs), only to control RTPs. The thing i'd like to find out is how to build a language where this kind of tethering can be built in. Using forth postfix syntax as the basic structure should make it easier. From [[http://en.wikipedia.org/wiki/Dylan_programming_language|Dylan]]: "In Dylan, methods are not intrinsically associated with any particular class; methods can be thought of as existing outside of classes. Like CLOS, Dylan is based on multimethods, where the specific method to be called is chosen based upon the types of all its arguments." This is basicly the same as in PacketForth. I saw [[http://www.rscheme.org/rs/b/0.7.3.3/21/doc/c914.html|RScheme]] has the same approach. So, the common for what i call polywords are [[http://en.wikipedia.org/wiki/Multimethods|multimethods]]. CODE ---- I started working on some [[/darcs/brood|code]]. The idea is like this: write the compiler/scaffolder in scheme, and generate a tethered forth from that, much in the style of BadNop, and i guess also [[http://pygmy.utoh.org/riscy/|riscy pygness]]. wiki/ZwikizwakiPages/EggForth Alternative to ChickenForth (see BootStrapping) The traditional, bottom-up approach to the bootstrapping problem reduces to writing a forth which can dump out machine code (in my case, C code to solve the portability problem.) The question here is how to add features. Once bootstrapped, the only external element is gcc.