ENTH Flux  aha
On November 30, and December 01, 03, and 04 of 2000 I exchanged some email
with Sean Pringle. He and I discussed his ENTH and Flux
projects and Machine Forth, Color
Forth and aha.
With his permission I am posting most of the email from our ongoing discussions because I think it will be of interest to some other people.
On 12/07/00 Sean sent me the URL of his first online documentation on the State of Flux.
Subject: Re: Colour / aha / Machine Date: Thu, 30 Nov 2000 23:09:29 -0800 From: Jeff Fox
Hi Sean, Sean Pringle wrote: >< > Hi Mr Fox. > > My name is Sean Pringle. I'm a University student in Australia and (through > the fault of my Uncle!) have been highly interested in Forth for almost two > years. > I've been rumaging through your plethora of articles on the UltraTechnology > Website for a couple of weeks now. Especially the few about Chuck Moore's > activities. They're very interesting! I like the ideas. > > Having finished (sort of) my ANS Forth called ENTH (the n'th forth!) for my > Pentium about a month ago I've tackled a Color Forth style system. I'm doing > these systems mainly to learn but with higher interests in mind for down the > track! I used the Pentium because it's all I have. > > I was going to post on comp.lang.forth but I saw your reception in the > 'compiler innovation' thread and wasn't brave enough :). I thought, with > your experience and your new system (aha?) you could tell me if I got the > point or missed anything? > > My new system is called Flux (state of!). It has things from Color Forth and > Machine Forth I believe. I think I interpreted your articles (the fireside > chats and your Thoughtful Programming mainly) correctly but I read a few > critical sentances a lot! > I've managed to get tail end recursion optimization going. The color tokens > work, I have eight or nine so far. There are also a few compiler directive > words. I've tried to keep the dictionary small and simple it currently has > just over 100 words. I have the A & R registers and the tail end recursion > looping construct. It sounds like a virtual machine modeled after Chuck's more recent hardware designs. He is using such a virtual machine for his Pentium based code in OKAD and his Color Forth. One of the main differences in Machine Forth style is that you use A a lot to not only split traditional @ and ! opcodes and insert auto-increment into code, but also sort of like one fast local. It changes the way you factor things. Also the smaller stack sizes we have, and the A register, typically lead to different looping constructs than those used in traditional Forth DO LOOPs are expensive in the extra stack positions they use. After working for a few years on P21 with only 5 or 6 deep data stack and 4 deep return stack we really got out of the habit of using DO LOOP or +LOOP constructs. The MISC chips have the carry bit on the stack and offer -IF -UNTIL and -WHILE which are often a useful alternative to IF UNTIL and WHILE and carry may be easier to generate than zero from many things. Chuck often used left justified numbers and would use + or +* in a loop to eventually generate the carry that terminates the loop. The restrictions are that +* will require adding a even number to an odd number so it will never generate zero in these loops. Incrementing or decrementing a counter is an expensive loop counter. using autoincrement with a pointer in A or R and testing for it equal to a termination value is quite common. Much of Machine Forth is looking at the actual machine and possible variations in code and being able to make the choice for the one that is obviously faster or smaller. There is not the ambiguity there is when you don't know what the code is going to translate into as there is with multiple targets etc. You are kind of in the middle, as is Chuck with his OKAD and Color Forth, because you are implementing a MISC style virtual machine (with A register at least) and implementing it on a Pentium machine. > There aren't many control structures. My 'accept' > function pretty much encompasses the editor requirements. The numbers are > converted at edit time and the words made into counted strings. I'm still > using Ascii characters for this. Ascii is fine. I may use packed Ascii characters too in Aha. I don't need an optimized character set like Chuck built for OKAD. I can see how and why he went to using Huffman encoding for his character set but I haven't seen an need to do that. In looking for ways to compress source code I had already considered using a technique from the traditional Forth compiler, a name dictionary, in the source code. It is used by the editor and compiler. For one things I need only store one copy of any defined word ascii string. All other source code references to a definition do not need to be in string format in Aha. They are just pointers into the defined name dictionary. So I can compress a word of any lenght into ten or twenty bits, and have an incredibly fast compiler that does not have to look up names, just follow a pointer to a CFA. It all the defined words (after they are defined) into ten or twenty bits rather than five or six (average) ascii characters and a space. That's from 5/1 to 5/2 compression and 1000x faster compilation of defined words in Aha. But the other tricks from Color Forth help too. The tokens that allow numbers and opcodes and other things to be picked up faster by the compiler without parsing and searching a dictionary. > The compiler loop is pretty darn quick! > Both ENTH and Flux are native, stand alone systems written in NASM. I don't > really like programming for Dos Windows or Linux, so I'm just making my own > standards up as I go along! How stand alone are these? Completely stand alone like Chuck's new Color Forth? He has a boot sector and that is about it. Then he reads complete tracks into memory and that's about it. Chuck not only wants to completely avoid Linux, Windows, and DOS, but as much of BIOS as he can too. Are you using some canned boot routines like from BSD or an RTOS or DOS or did you write a primitive level boot routine like Chuck has done for the Pentium and (of course) we do on MISC chips? > The resulting code is very nice. I was a bit apprehensive of the colors at > first but using the color tokens is quite nice. The system is probably One of the things about Aha is that it uses tokenized source. This means the compiler, editor, debugger, etc can do some new things. I can do more error checking at edit time because more of the traditional compilation techniques happen then. So errors can be caught when they are most relevant and in the mind of the programmer and dealt with sooner. Many errors can be caught at edit time. I can even implement a smart editor that looks over your shoulder and helps write code. But the editor or editors can be different than the compiler. I can have a Machine Forth editor, a Color Forth editor, an ANSI Forth editor, and HTML-ANSI editor, etc. that all use the same compiler and same tokenized source. The look and style of the source code is factored separately from the compiler and internal representation. > around 9k and runs off a Floppy. It's this size because of the Pentium 32 > bit architecture and the setup tables you need for that processor to run in > protected mode. That sounds pretty good. 9K is very small compared to a Floppy and even smaller compared to memory on Pentium Machines. It sounds like you have a real stand alone boot system like Chuck. It sounds nice. > Some of the functions are probably not as atomic on the Pentium as ShBoom or > your F21 but they are faster than ENTH was! My Uncle has been building small > general purpose microcomputers currently with motarola processors that run > an ANS Forth of his. As soon as I can give him the outline of my Flux he > wants us to implement it for the micros (ie - the 68HC11 model needs all the > speed it can get!) and use the 80x86 system to talk to them. I understand. Sounds good to me. > Anyway, though you might like to know what your essays inspired! Also if > there's anything you have found that would be interesting to put in that > might make the system faster or simpler, I'm all ears! Thanks for your > magnificent library of articles on the net. If you have access to a relatively fast internet link Chuck's Color Forth 2000 presentation is currently playing in the streaming video theater. I have not transcribed it to HTML because it was long and had lots of writing on the board. It explains the changes in 2000 with Huffman Encoded characters etc. that Chuck has been doing. I am going to remove part 2 and upload part 3 in a couple of hours. I am excited about your project. Will you make it PD or use it for commercial work? Will other people get to see the code? Will you do a writeup and explanation of it and post it anywhere so I can read it or post a link to it. how much of the information you sent me on Flux are you willing to make public? Chuck would be happy to hear about it. Other people would be interested. But you might not get too much positive feedback in c.l.f. You might get some interest from email if some information gets posted there however. I am planning to do a presentation for FIG next month on Aha. I will emphasize compiler internals, show code, explain design decisions, and talk about lots of stuff but not talk about Color Forth per se. I will want to show the tiny amount of code it will take to compile tiny source into tiny object code at an incredible rate. I am going to be using about 20K for all the stuff I see coming in aha and a few desktop applications. The upper limit compile speed for aha will be about 100million Forth source words per second. For the board and memories I will be using in the first test I figure the average speed will be between 2 and 20 million Forth source words per second. To compile 20K cells I might use 60K source words, just a guess at this point. So far the comiler looks like it will take between 100 and 200 cells. So the compiler should be able to compile itself in something like 30 microseconds. The complete system boot code, compiler, OS, GUI, editor, appliations etc., I don't know, a few milliseconds. > Cheers, > Sean Pringle Jeff Fox Subject: Re: Colour / aha / Machine (2) Date: Fri, 01 Dec 2000 09:45:21 -0800 From: Jeff Fox To: Sean Pringle > Sorry, what does +* do exactly? +* is a conditional-non-destructive add. It is the multiply step instruction that Chuck wanted for multiplies in OKAD. It is the equivalent of: : +* ( n1 n2 -- n1 n2 | n1 n1+n2 ) DUP 1 AND IF OVER + THEN ; If you wanted to multiply to 8 bit numbers to get a 16 result you would shift N left eigth times then execute a sequence of 8 copies of +* 2/ nop nop followed by push drop pop to clean up the stack. If you put 1 in T and 2 in N then execute BEGIN .... +* -UNTIL it will add 2 to the value in T a half million times until it generates a carry. DUP 1 AND IF OVER + THEN in 1 clock. If I used the same kind of advertizing mips as other people I might claim that F21 could thus perform seven ANS Forth words in 1.2ns or 5600 MIPS. But I don't. > But yes. It was a bit of a toss up sometimes. I tried not to overuse the A > and R registers in the Flux Kernel as this meant that certain words in the > Kernel could be used without fear of their modifying those registers. In > loops that were interacting with the user and time wasn't so critical, I did > it the clumsy way! I understand. In P21Forth A was used as the IP. It had to be saved and restored in most Forth CODE words because of this. We did something similar at iTV. I noticed that this was very different than Chuck's native code for MuP21. His most common sequence was " ... # call" where a literal load was in same word as a subroutine call. he tended to pass arguments in A from word to word to word not as the IP but as a parameter or pointer. more assembler style than traditional Forth style of coding. I wrote 30 different compilers with lots of different optimization techniques to explore the automated use of the A register. > Immpressive! How complex is this editor becoming? Do you feel it's more > important to compressed source code or interpret it more quickly? Realising > that the first can sometimes lead to the second. I haven't designed the editor (editors). It will combine some of the features of the machine Forth compilers and the simulator interface that uses code decompile. the editor is made more complicated and slower by moving some compiler steps into edit time. But editors are easy to do. And moving things back, not forward in time is Forth style. I once made a bet with a coworker when I worked at Pac Bell. We had spent a day installing an editor on 250 machines in our wing (7000 cubicals in this office.) The employees were trained to use this editor to do certain things in a class. It was terrible overkill. The product came in a big box, needed 25 diskettes to do an install or upgrade, and was as slow as you would expect for something so large. I bet my coworker that I could write a knock off editor with all the same keystrokes and functions that the users were trained to use so that they could use my editor as an alternative to the big one. I would leave out most of the advanced features that these users were not trained to use and were not using and I would add a bunch of useful features that the big product did not not have but which I would find useful. Instead of 40 megabytes the editor I would write would be small and fast. Furthermore Pac Bell could give it to thousands of employees rather than spending $300 per copy for thousands of copies of the other editor (not that they wanted to save money on such things). The bet was not whether I could write such an editor, the bet was whether I could deliver it the next day. That is the editor that I have been using most of the time for the last seven years. I too had been trained to use this other editor so it was easy for me to use and it had extra features I could use and yes I did it that night and delivered it the next day. The first editor in aha will not have a pop-up agent with my face in a window and my voice speaking or holding the user's hand. It will not have all the bells and whistles that it will eventually have. It will be a simple source code editor that will also pack the source code tightly for the compiler to use. The initial one will be pretty small and simple. I like the idea of making the editor slower and the compiler faster. I only type about sixty words a minute, or a few characters per second and often there are gaps when I am thinking about something. Editing code is not just mindless typing without thinking. So it makes sense to me that the editor should be able to do more stuff at edit time including error checking and various forms of code optimization, source code compression etc. I remember one of the iTV programmers telling me that he had added a new hard disk to his system just to hold all the copies of eMacs that he needed. He routinely used a half dozen different versions of the editor at different times because they all had different features that he like to use. So he needed a gigabyte of disk space just for his editor(s). I know that this is the way many people think. They must use those tools. They would not consider writing their own editor. Writing your own editor is very basic Forth thinking in my way of thinking. It is a very personal thing. Chuck jokes about how basic and important an idea it is. > Also do you most of the work while the user types or whenever you store/save > the source? Yes in the editor. A translator could take ASCII source representation and convert it into a tokenized representation also. I may make several editors including some with no keyboard. For an F21 in a mouse I could make a mouse only editor using some unusual user interface techniques. I also like the idea of making a completely visual editor that displays source in a flowchart format. But yes, even with a keyboard version there is time between keystrokes. Chuck executes or compiles each word indiviually rather than line by line. In fact Chuck doesn't really have lines. I will also go word by word rather than line by line in aha. > Mine 'prepares' each line of source as soon as you move to the > next line. This means that I can point exactly the same 'accept' function at > the editor or the terminal and there should be no noticeable delay at any > time. I know what you mean. Traditional Forth design requires scanning or parsing to the end of a line at compile time. I will avoid all of that. > I am not sure I can push my editing as far as making the words merely CFAs. > The reason is (and I'll have a think about this!), Flux has a basic > multitasker which I want to implement the 'Flash Tasking' on. That is to > say, small transient tasks that get compiled and executed on the spot to do > a simple job then erased. Having lots of small tasks that appear and > disapear could mean I can't know exectly where or when they will be compiled > at runtime and thus where the various CFAs are. I'm not sure. I havn't > decided about the feasability or use of this style of multitasking yet. It > may be too complex a system and deafeat Flux's purpose. It may end up too > slow! The CFA are only set at compile time. The slots for them, the dictionary exists at edit time. Direct pointers to CFA fields in the dictionary as representation of defined words is fastest but requiers that the source code be at a known and fixed location in memory at edit and compile times. Relative pointers are bit slower but would allow the use of CFA field pointers in the source structure and still keep the source relocatable. At compile time when a defined word is compiled the CFA field gets set in the source and used to represent defined words from them on. The editor will display these pointers as the strings in the defined word record. Since the CFA get set at compile time when you bind to an actual compilation address I don't see that it would be any problem for what you are doing either. Following a direct or relative pointer to a CFA field that gets set at compile time to compile a defined word is going to be so much faster than any dictionary search mechanism and that it is very attractive. It is also a form of compression at the same time, that is nice too. One important concept in Forth is pushing things backwards in time. It is important to do things earlier and one rather than later and many times. This is what I am trying to do in the refactoring of the editor and compiler. It is what Chuck does. > Everything is all my own code. And yes, some of it is fairly primitive! I > have a simple boot sector which uses BIOS to do the initial single track > read to get the system image. This is the only time BIOS gets used. Once the Very nice. > system 'lives' it has it's own hardware interface routines though only the > basics. (Much sweat, blood and tears given to get some going!) It's knows > nothing of any other Operating System! We were thinking about putting Flux > of ENTH into a boot rom to replace BIOS on the PC but that hasn't happened > yet :) Very cool. I made a Forth ROM for the first micro I ever owned. It was the first commerical microcomputer to have a boot ROM! The models before that used a single step circuit and a front panel to toggle in your boot code bit by bit whenever you started the computer. You could use this to enter your loader and load more from a paper tape or cassette. I have always felt that personal computers should boot up in a fraction of a second. It is rather pathetic that boot times have gotten longer and longer as the processors have become faster and faster. Hurry up and wait. I joke that the Windows interface is not a point and click interface. Often I know what is going to happen when I click. I point and click then move the pointer to the next location I want which usually takes a fraction of a second. Then I wait, and wait, and wait for Windows to respond. The game I play is to try to have the arrow already positioned over the next button I want or the next menu or whatever so that when it eventually comes up I am already there. I make it a sort of game, it gives me something to do while I am sitting there waiting for Windows to respond. I am pretty good at being way ahead of where Windows is in real time. If I have to move the arrow a little to actually position it over the new button that I want I try to learn to anticipate Windows (batch like operation) better next time. It is kind of pathetic actually. I remember the first time that I read that Microsoft said that if you were running MS Word on your Mac you would need a 68030 because a 68020 was too slow to keep up with your keystrokes if you were a fast typist! I had thought that the 68020 was a killer CPU and they didn't think it could keep up with my typing! > >Sometimes I forget that one still can only bring up these topics > >in c.l.f at your own risk. There is a list of people who will try > >to make you look like an idiot should you mention any of these > >"controversial" topics. > > That's why I didn't even try. I can understand. I liked the Poem that Chuck presented at Forth Day 2000 about coloring outside of the lines. "Somedays I don't have the courage for it at all." > Yep, I've read the 1999 and 2000 Fireside chats. As I said, some sentances > fairly carefully! I'll keep an eye on the aha pages. Yes, you do seem to have not only grasped the concepts but dug in for hands on experience and knowledge. That is great. Maybe Chuck and I can learn something from what you discover in the process. Maybe other people will be able to learn something from it too. > Both ENTH and Flux would be PD I imagine. I have no commercial application > for them! Even so, Flux took about two weeks to write. I could just do > another for commercial activities someday. Yes, I will do a writeup. If only > for my own documentation purposes. I would certainly post it. You would be > welcome to read and link to it! Yes others could see the code if they > wanted. There's not that much code to see really! cool. > Wow, Chuck Moore hear about it? You know what that sounds like to > us mere mortals? Chuck likes to hear about people who understand his work and try their own experiments. That is what Forth was like in the old days before it became 'standardized.' Chuck likes to hear about other people experimenting with MISC code, Machine Forth, Color Forth, and the associated concepts or other new ideas. So do I and so do a bunch of other people. You may find that the MISC mail list is a more productive forum for discussions of these kind of ideas than say c.l.f. I know that there are people there who would be interested in your work on ENTH and Flux. > It can all be public. Not worried on that score. It would be good to have > others interested! I know personally only one other Forth Programmer and > he's family! Mind you, I would rather people show absolutley no interest at > all than stop to tell me why they have no interest, unless it's polite nasty > comments! "The teacher frowns. The other kids call me dumb, or wierd, or retarded." I know what you mean. Chuck knows what you mean. But it goes with the territory. Not everyone wants to explore uncharted spaces. You never know if you will find something interesting or not. There are no road and no maps. I guess I have tried to leave maps for other people and that Chuck has also made an effort to do so. But even so it is still a small group of people who will want to go into the wilderness even with a map. Even today, most people in the world never go very far from where they were born. Most people are not explorers or pioneers. But we just leave them behind and don't worry about them too much. They have a right to stay home if they want to and think we are crazy for wanting to explore new spaces. > Those compile times you quoted are certainly 'before the finger leaves the > key jobs!' I've not timed Flux yet but I don't expect anything like that. > Maybe one day! The biggest factor is completely eliminating dictionary searching at compile time. Look into what I said about the CFA mechanism above. The upper limit I got for some code on an F21e in SDRAM is compilation of about 120 million Forth words per second. (that was NOT for compiling on 1000 nodes in parallel! hum, 120B Forth words per second compilation speed...) The numbers I gave you were based on a low 2M estimate for F21d in DRAM on more average code. If you do the math on compiling a few hundred words of source when the upper limit is 120M Forth words per second you get very small numbers. Beating windows by 100x or 1000x on a lot of things is not very difficult. Sometimes we can beat windows apps by 10^6 or 10^9 on some things, that is more fun. For this reason I often ask people to post units. I see the same thing expressed in Seconds by some people in milliseconds by others, in microseconds by some, and occasionally in nanoseconds. When you talk to Chuck about hardware things move into picoseconds and femto seconds terms. (then there are the optical computing and other exotic technology people who also use sci-fi numbers and some of them realize that Chuck's style of designs would be a good fit to what they are doing. Single Electron transistors, quantum tunneling transitors, diamond semiconductor, optical transistors etc. Those folks would not consider implementing a Pentium, but a MISC chip is doable. These were the futures that got me interested in Forth machines fifteen years ago.) > Once again, thanks for your interest. It's encouraging! > > Cheers, > Sean Pringle Your welcome. Thank you for your interest and your work on similar ideas. It is nice to exchange ideas with someone who gets the concepts. It is much better than dealing with the people who have knee jerk defensive reactions or who put their hands over their eyes. Jeff Fox Subject: Re: Flux rewrite Date: Sun, 03 Dec 2000 22:10:02 -0800 From: Jeff Fox To: Sean Pringle Hi Sean, Sean Pringle wrote: > > Hi Jeff. > > I wrote another version of Flux on Sunday. My coding productivity seems to > have increased markedly using the single line definitons. I am having much > more fun now! It's never been this fast! Good signs. Impressive. Another form of aha experience, and fun is imporant. > Anyway, I implemented the CFAs in source code ideas you were explaining. I > am not sure what format your source took exactly so I made mine up as I went > along! I think what I have are what you called relative pointers. The actual > source is a string of pointers (and color tokens, etc) that are offsets into > a list of all words used in the source. The list entries look similar to the > dictionary headers and contain both the word as a counted string and a CFA > slot. CFA slots for kernel words are filled at edit time and CFA slots for > newly defined words are left empty and patched at compile time as soon as > the word is defined. It seems to be fairly quick. That is exactly one of the ideas I considered and mentioned to you. I plan to implement a direct pointer compression structure, but who knows, I might decide to change to a relative pointer to make it freely relocatable. At the moment I am trying to get as the first target the fastest possible approach and second the most compressed represntation of source and source/object combinations. So I plan to combine basically three main things, compressed defined words using CFA pointers to a dictionary as above. Second are tokenized words that are represented with only a few, five or six bits. I would prefer five and could do it but I think six is better, I will have to profile real code. Also real code will have a way of adapting to the best representation in the system as well so it is a little hard to picture those details at this stage. The tokenized Forth words can be packed so they create smaller source and can be read at about the same speed as CFA pointer words. The third is the packed opcode format. This is for whatever percentage of the code can be represented as packed opcodes without further symbolic representation. The rate for simply moving these 4 opcodes per word structures and/or removing them from the source object is of the course the simplest and fastest thing the compiler can do. It was the first code I wrote, to recoginze the opcode token records, get the count, and transfer them from source to object. That is what sets the upper limit in aha on F21 at about 100,000,000 Forth words (opcodes) per second. The other thing that is nice about this 100M Forth word per second compilation, it only takes a half dozen words of code to do it. That sort of thing sort of has to be that way, the fastest routines must be short ones. Sometimes computed jump code arrays are fairly big. It is the technique that Chuck and I have both used for inlined pixel transfer code in the GUI. I could leave out the function tokens and do aha with just CFA pointers for everything. It would be slower but slightly simpler, it would cause some of the source code to be 3 or 4 times larger. BTW like code tokens the representation of everything can be done without redundant representation after compilation. You can throw away the CFA pointers for defined words and only keep a copy of the dictionary of CFA and counted strings so that defined words can be displayed and edited by name in the editor or debugger. You need only keep some marks to where things got moved for opcode token records so you can further compress the source representation in memory or on storage once it is linked to object code. The entire thing, all Forth words, comments etc. are still there and look the same in source view. But once again this is a feature of the system, that source and object code are incredibly small for linked source level debugging and the tools are also incredibly small and fast. The functional tokens will use a simple jump table so they only take a few memory accesses and are almost as compressed in representation as the opcode tokens. The defined word pointer token records will also be able to be processed very fast and compiled very fast. I don't have actual performance numbers because I haven't written the code yet. You are ahead of me already in your implementation. That's nice. Speaking of GUI, Chuck has a background task to update the graphic display. It was running at something like 35 to 70 Hz. That means the actual screen would be repainted 35 times a second by the CAD software or anything else running in Chuck's Color Forth. He recently got the new graphics board programming working and said that OKAD (and therefor Color Forth too I guess) will be in hardware assisted 3D. > Does this seem to resemble your idea of things? I get the idea it might be > still somewhat more basic than aha's plans as it still simply builds > threaded code for the main part whereas aha would have a significant number > of opcodes directly coded into the source and coded inline by the compiler? > And more? Yes those are my ideas too. CFA pointers for defined words, and function and opcode tokens are some of the things I am doing and a few more. aha is certainly about recognizing the match when you see it and saying "aha!" I had the aha experience about the representation of defined words with CFA pointers and a dictionary in the source code. I had other aha experiences regarding the way I have Forth opcodes that correspond so simply to source code in some cases and that I can also use a function table as a third compressed source/fast compile mechanism. I have been working with Machine Forth in many different forms for years. I have tried it many ways but have only been watching and reporting what Chuck was doing with Color Forth and new ideas there. Machine Forth is pretty old stuff to me now after ten years. I wanted to try new ideas and I knew the goals. Machine Forth programs on F21 are remarkably small and fast. Compiling them is relatively fast with a conventional compiler but memory limitations are a factor when you start talking about source code/compiler on flash on these potentially very small systems. I had been working with a lot of tools with debugger and symbolic debugger interfaces but had not done one with complete link to full source code including comments on the target system mostly because of size. ASCII string source representation takes up too much space that you want for more programs and compressed bitmap images, sounds etc. I knew what Chuck was doing with tokens was potentially much faster than traditional Forth compilation techniques so I examined very closely what exactly Chuck was doing, what I was doing, what I wanted to do, what all the possible pieces might be, and how they might fit together and I said, "aha! I've got it. I can see how to compress the source code way down and compile at fantastic speed at the same time and several different ways too!" Yes, I plan to do more than just the CFA pointer and dictionary in source represenation as a source code compression and fast compiler technique. That is part of aha. I may get to something very much like what you are now doing or that part might just be a little different in my implementation. It will be most interesting to compare those kinds of details. I'll bet we sort of have to do a lot of things in a similar way, but we have not discussed so many details that there are so many design decisions one can make about implementation details. And you are on a Pentium and I am not. That is a big difference in itself. You are doing something more like Color Forth that way and with an aha compiler feature of using CFA/String pointers to represent source words. It is clear to me that Chuck is looking for things that work well on his chips, like F21, but is also making decisions about what maps well and what works well on the Pentium. > I think I am starting to run into the Pentium's non-MISCness. I am sure you must have to confront a lot of that. I know there are a terrible number of details on a Pentium to deal with. I can only admit to Intel assembler up to 8086-80286 and stopped looking at assembler details like I did before after 386. I was very focused on studying various Forth chips. But I know enough about them to follow the things that people who work with them at that level for a living or like Chuck does when they talk about all the things that you have to consider to make wise choices in coding. I tell people that I feel sort of spoiled that way. I mean things have just been so simple whenever I have done coding on these things. I hear Chuck complain about Intel headaches and other people brag about how they understand the complex details. > My editing routines still form a line-editor as oposed to a word-editor. > This allows me (and my habits!) to work on a single line of source using > conventional editing styles like single character backspacing, etc. The line > of source is converted into pointers and list entries as soon as I move to > the next line. This could result in an editor something like the F83 line > replacment style I suppose though I've yet to find out! I haven't designed my editors yet for aha. I have various user interfaces for the various editors I have done. Chuck has talked about the details of his editor in Color Forth. It is a full screen editor but the focus is the center of the screen where you edit. It only moves left and right and only on word boundries. Changing a word means replacing it. He has a very simple and primitive interface. I expect I will start with something similar but a little more full and conventional. I may not even make the first one a Color Forth interface. As I say I haven't decided on what editors I want. I have thought about one for a mouse only. Well two for mouse only. Thumbwheels for opcodes always worked nicely. Function tokens might work the same way. I had thumbwheels, as it were, in the first simulators and wrote them before I saw how Chuck did the same thing in the OKAD chip code editor. As he said it works nicely when you only have five bit opcodes but turning an instruction wheel on a Pentium does not work very well ;-) I have various editors for full screen text editing, but mostly have thought of ways to do it without a keyboard as well. Using graphics only and thumbwheels and pull down menus and pop up virtual keyboards with smart dictionary assisted word completetion. and all of that is independent on whether you make it look like Machine Forth or Color Forth. Well an inteface that looks like graphic flow charts and symbols would be quite different and it is the other wierd mouse only interface I have thought about. Maybe I shouldn't be thinking about all the editor variations I could do at this phase. I need a compiler, then I need source code for the compiler. That means a translator or editor and I am sure I will just start with something based on something I have rather than start with the final choice of editor. I will first target compiler the aha compiler using Machine Forth. Then produce an editor to pack aha source code. then I can bootstrap an editor as aha source code and metacompile changes to aha and the OS and GUI as originally intended. So having the ideal editor on the target is still down the line a ways. > The resulting source code has no 'line' structure though, so the compiler > just runs straight on through, word to word, without needing to scan for the > ends of lines. I think though that I have enough information in the > structure of the source to enable a fully fledged editor to reformat it back > into the original lines. A compromise! It was a requirement for my design, fully recoverable, no loss of anything considered source. The only "loss" is that you won't be able to edit the source with the Ascii text editor that you are using now. But as I say, you are not using an Ascii text editor on F21 right now. So there is no real loss at all. Of course people who must edit with Word or Emacs or some other thing like that may complain that you are not using normal ascii source. Right. I can complain that they do. But I don't need to, I can just show them that I have all the features I wan: small size, high compilation speed, simplicity, the ability to write an editor that does what I want etc. The fact that I can't use Emacs I consider a design win. ;-) > I think I'll keep this line-editor setup for a while to see if it works. It > would be interesting to see a word-editor though, as well. Maybe I should do > a Flux with one. Have you used a word-editor a lot? Is it comfortable? I am used to either an ascii text editor or an opcode/hex editor. I will not lose anything in aha it will just be easier and better when I don't have to deal with these other constraints and can pick the constraints that don't feel too constraining to me. :-) As a bare metal programmer I have been known to be comfortable with a one line block line editor. I have used the one liner to write a windowed editor with touch pad control etc. so I may do something similar and write a series of editors with increasing sophisitication. > What I wanted to ask you was: > If I write this up and put it on my website, do you mind if I quote yourself > and Chuck as sources of inspiration, link to your website and explain how > your ideas influenced mine or were directly used? No, not at all. Please do. I am excited to hear about how much Flux is like Color Forth and aha. You know what they say about imitation and flattery. I was thinking of even putting some of our email conversations onto a web page at my site because I think other people would be interested and my site does get visited about a hundred times a day. If you don't mind the idea I will be sure to let you review the edited version of the converstation before I would post links to it that would allow other people to see it. There are also people in the MISC mail list who would love to see a copy of some of our conversations about the design of Color Forth, aha, and Flux. > Doesn't matter if not. I'm > not really sure what to write yet. I don't really expect a lot of interest > but I don't want to direct yet more flak onto you because I've expressed my > ideas ineptly! Pointers? I am sure I will be very happy with your explanations of the details of what you are doing. There is a lot of it that has to be different than my implemention. It is great that I will be able to look at what you tried and what you did and how it worked. More experience to learn from. > How do you come up with the times and figures for the F21 compiling? ie 120M > words per second. Can you do this because the F21 is your processor and you > know the clock cycles per instruction? Yes, and because I have already written the code and it is so easy to calculate the timing of code on these simple machines. You count the memory accesses and add the memory access times, you add the time of any opcodes that delay the prefetch of the next instruction (prefetch only applies to linear code and is delayed by any memory access instructions in the word). So with the fastest memory possible I can pump words from source to executable object at about 30M words per second. Each word represents up to four Forth language words compiling 30M cells means compiling a maximum of 120M Forth source words presented by those opcode tokens. Defined words are not compressed as much or as fast. Function token words are almost compressed as much but not as fast either. So it would be truthful to say the maximum "burst rate" of the compiler is about 120M Forth source words per second. Slower memories, and more defined words and even comments will slow things down. But even if I use a single string of records for everything the compiler just jumps over comment strings with a count. It doesn't parse them by character or anything that slow! A source level debugger/editor also needs to link, display and edit comment records. But they don't slow the compiler down much. I don't know what the actual speed will be but based on the fact that the object code is so damned small and much of it often is unambiguous opcode sequences that can be represented by the opcodes themselves as tokens and that the other types of records like CFA pointers for defined words will also be fast and the records are small and amount of object code that does the job is small everything should be ridiculously fast. I figured 2M words per second for an initial guestimate overall. Then figure how much source code it takes me to generate real code. The F21 in a Mouse demo, that has been confused for Windows, is 600 words of object code total. The boot code, the OS, the GUI, the graphics code and application is 600 cells total code. and I didn't try to squeaze it or anything just keep it simple, and it is just a simple GUI desktop. ;-) Now add a hundred words for the aha compiler. How long should it take for aha to comile itself or the one of these tiny systems? However you figure it the numbers are ridiculous. At say 2M source words per second to get 100 object words? It is not like I am compiling megabytes of code from slow OS Files or dealing with brain damaged API or watching virus protection software slow things down another 10x or anything like that like other people have to deal with. On boot some stuff comes from ROM or FLASH into memory. Then bang, in a few microseconds you compile whatever you want. > I can't seem to find exact times for > Pentium instructions, people say that I can't because of the unpredictable > effect of this processor's pipelines and predictions etc. I suppose and > figures would have to be 'on average'. There is tick timer on Pentium. It gives very precise timings of code sequences. If you don't have any interrupts causing unpredicable timing on the pipeline stalls and cache misses that they will cause you can get simple and very precise timing from the machine. I know Chuck does this. I know other people do it. It is Pentium only, not 386 or 486. If you have interrupts or multitasking causing things to vary then you need to take a bunch of timings and do an average and worst case. Phil Koopman wrote a great article for the Embedded Systems journal about determinancy and embedded systems and Intel chips. It was very illuminating. The real problem for real-time are those 1% profiles that take 100x as long as normal! So the shorter the sequence being timed the more variation that is possible. But you can get very precise cycle timing on Pentium. Someone gave me an example in email this week. > I would like to compare ENTH and Flux compiling similar applications and see > what the new techniques can do! Me too. I think other people would too. The aha documents have been getting about 30 hits a day since I posted them. That is an indication that people are currious and checking it out. They would love to see charts and graphs and real numbers and real code. Some of them will want to try it themselves too. You might be suprised. There have been a lot of people asking about getting a stand alone Color Forth. The problem is that Chuck's isn't portable, isn't documented, and isn't available. And it compiles itself so they can't compile it themselves. I got a copy of the first stand alone Color Forth disk to try to my machine because it happened to have an ATI graphics card. But it would not boot. So there might be quite a few people who would want to get a copy of Flux. You might be quite suprised by the response. Now I know the only other person who is working with F21 is interested in aha. But there are a lot of people who have Pentium PCs who have expressed interest in a stand alone Color Forth on diskette for a PC. They have wanted Chuck to deliver one, but Flux might be better for several reasons. It should be more portable. Chuck considered writing for generic VGA but went for very hardware specific ATI graphics card details and then upgraded to a newer 3D graphics card. Flux might be something more people could run, and it might easily be available before Chuck gets around to releasing a version of his stand alone Color Forth. Then he has the Huffman encoded wierd character set designed for OKAD etc. and you are using ascii. > I am aiming to have Flux with sufficient tools running off the floppy within > a few weeks so I can use it comfortably and productively with my laptop > _without_ Windows on the harddrive! PD is nice. I have put the aha design document out in public as I wrote the first code. I figure I will include actual code at some point. But there is no F21 audience like there would be for a Pentium version. I am not focused on Pentium so I am very pleased that you are using Pentium but exploring some of the same ideas that Chuck and I are experimenting with. One idea to consider is to make ENTH and Flux low cost products in the UT store. Just to cover the cost of duplicating disks and producing a little more user level documentation. People might prefer that over the stuff where people only document for their own internal use. With the exception of his presentations to FIG Chuck is only documenting for his use or internal use at iTV. I am the person who has presented the info on the Internet. Just a thought. You certainly don't need to put Flux out as something available in a store, or in the UT store but I would want to put it there whether it is free or not. But you might like the idea. I think some other people would even if it is still mostly and experiment in progress. That is the nature of everything at UT more or less anyway. But as I say we might kind of be suprised by the number of people who might be interested. If nothing else I would like to make an html page at my site (with your permission) about our conversations about Color Forth, aha, and Flux. (nice phrase, I liked it more the second time. ;-) the Fox Subject: Re: Flux rewrite Date: Mon, 04 Dec 2000 19:58:01+1000 From: Jeff Fox To: Sean Pringle Hi Sean, Sean Pringle wrote: > > Yes, I will have to think some more about more ways of compressing the > source for Flux. Though I might run with this for now. After all, if I make > the source yet smaller, all that will happen is the only first few tracks of > all my Floppies will get worn out while the rest remain pristine! :-) > Tell you what! Flux uses a small fraction of the opcodes available for the > Pentium. The rest I either don't understand (often!) or can get better > performance from a few simpler ones in the right pipelines. As yet, I'm not > convinced I ever want to be able to claim: 'I know the Pentium!' > > >As Chuck said it works nicely when you >only have five bit > >opcodes but turning an instruction wheel on a >Pentium does not work very > >well ;-) > > I think he might have that bit right :) I assume you've used FPC. It had a > nice idea in the little window you could access at the terminal (by hitting > an arrow key I think) that let you pick from a list of the most recent > words. I found it useful at times. > > >I see the fact that I can't use Emacs as a design win! ;-) > >seen as a design win by me! ;-) > > Amen. I like to think that what I am trying to write is a _stand alone_ > system. If I am using somebody else's text editor then he is defining my > system, my comfort, the format of my source, the speed of my compiler ... > and taking all my fun away at the same time! > > >There is tick timer on Pentium. It gives very precise timings of >code > >sequences. > > Ah yes. I think I even wrote some code to detect and run it when ENTH was a > lad. I have a look :) Thanks. > > >But as I say we might kind of be suprised by the number of > >people who might be interested. If nothing else I would > >like to make an html page at my site (with your permission) > >about our conversations about Color Forth, aha, and Flux. > >(nice phrase, I liked it more the second time. ;-) > > > >the Fox > > To tell you the truth, I've not thought of much beyond my own escape from > Windows! But yeah, ok! There would certainly be good exposure at UT. > Feel free to make the HTML page on these conversations. You'll have them all > confused as I'm sure few have heard my name before! > It makes UT a central repository as well which makes these ideas easy to > find all in one place. I like the idea of the UT store though you might want > to see if my code is worth a jot first! Escape from Windows. Sounds like John Carpenter movie. Esape from New York. Escape from LA. Escape from Windows. ;-) > Speaking of GUIs and stand alone systems before, I have some resonably > reliable code to drive the floppy, keyboard, DMA, timers, IO etc. My Uncle > works at a University and carries a copy of ENTH in his short pocket > cunningly testing it on any unused (unwary?) machine :) > The video for Flux is running in 80x25 or 80x50 VGA text modes. Up to the > present, this has been fine and I can get enough colors for tokens like > this. Do you know where I might get some information on driving the generic > VGA graphics modes? My searching on the net must have been in all the wrong > places. I understand you do some of this stuff with F21 boards and Chuck > with his system? I wouldn't mind a simple GUI. That sounds good. More on that later, I have to go now. Jeff