Forth - The New Synthesis
CC Attribution 2.0 Belgium:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Hoffmann, Ulrich
The "new synthesis" of Forth is an ongoing effort in spirit of the Forth Modification Laboratory workshops. Its aim is to identify the essentials of Forth and to combine them in a new way to build systems that can scale-down as Forth always did and can scale-up to large applications and development projects. The new synthesis is guided by the two principles biological analogy and disaggregation. We scrutinize many aspects of traditional and modern Forth implementations trying to separate techniques that are normally deeply intertwined. After isolating the techniques we thrive to combine them in new ways. The talk describes two mile stones of the ongoing project: preForth (< 500 LOCs) a minimalistic non-interactive Forth kernel that can bootstrap itself and can be used as an easy-to-port basis for a full Forth implementation or implementing other programming languages. It is an open ended language that inherits functionality from the target platform's development tools. seedForth (<550 LOCs) a minimal stack based extensible programming system accepting tokenized source code. seedForth can be extended in various ways: as stand alone applications, as fully interactive systems, as umbilical target system for embedded system's programming We try to use Forth wherever possible in order to minimize semantic and formalism mismatches. Everything should be readily available - no hidden secrets. Of course many of the subjects we are looking at have been used by others in the Forth community and outside - we are dwarfs standing on the shoulders of giants - however we believe our new synthesis to be original. Our findings in the new synthesis so far can be summarized: high level inner interpreter (EuroForth 2016,) We showed that a traditional Forth indirect threaded code virtual machine can implemented in high level Forth bringing threaded code manipulation tricks to any Forth implementations. stacks for structured data (Forth Tagung (convention) 2017, german.) Stores and handles structured items (strings, queues, lists, stacks) on stack and return stack. No memory required. Shows how terminal input and number output can work without random accessible memory. handler based outer interpreter (EuroForth 2017,) This demonstrates a very simple modular architecture for the Forth text interpreter separating interpretation and compilation actions for parsed tokens by handlers that possible consume and process a token text or pass it on unprocessed. preForth, simpleForth, Forth (Forth Tagung (convention) 2018, german,) Presents preForth, a minimalistic non-interactive Forth kernel that can bootstrap itself, simpleForth, still non-interactive, which adds memory and control structures and \textsf{Forth} a simple interactive Forth bootstrapped from preForth/simpleForth. See below for details. String Descriptors (EuroForth 2018,) We revise different Forth string manipulation facilities and present string descriptors, an intermediate string representation balancing utility and ease of implementation. Regex (part of string descriptors paper, EuroForth 2018,) Presents a simple implementation of regular expressions extended for Forth's demand to detect space separated tokens and intended to be used in the token detection part of handler based outer interpreters. seedForth a minimal stack based extensible programming system accepting tokenized source code. seedForth can be extended in various ways (EuroForth 2018). This talk will go into the details of preForth and seedForth and will how the source code tokenizing works as well as how to extend seedForth to become a modern interactive yet minimal programming environment (<1000 LOCs). References Implementing the Forth Inner Interpreter in High Level Forth, Ulrich Hoffmann, EuroForth Conference 2016, Reichenau, 2016 Stack of Stacks, Ulrich Hoffmann, Forth Tagung 2017, Kalkar, 2017 A Recognizer Influenced Handler Based Outer Interpreter Structure, EuroForth 2017, Bad Vöslau, 2017 Bootstrapping Forth, Forth Tagung 2018, Linux Hotel, Essen, 2018 A descriptor based approach to Forth strings, Andrew Read and Ulrich Hoffmann, EuroForth conference, Edinburgh, 2018 String descriptors on GitHub-based-strings preForth and seedForth on GitHub
 Yeah, okay. Hello, welcome. Thank you very much for joining. I will talk about FOSS and some experiments that we did with FOSS. So my first question is who has heard about FOSS? Okay, who has written a FOSS program? Okay, I see. So I try to be with a terminology close to normal computer science terminology, because FOSS has its own kind of language I try to be as understandable as possible. I will talk about the new synthesis. It's a project that's ongoing and we try to understand the essentials of computation and find minimalistic ways to realize things and build a basis of computation. And for this we build a family of FOSS-like languages with restrictions and certain properties. I will go then and talk about the ICE concept. I think most of you wouldn't have heard about this before, but it's about 20 years ago that Charles Moore, the inventor of FOSS, proposed the ICE concept. So we will look at this and see that other programming languages have this as well. And today I will focus on C-FOSS, which is one of these languages in the family of things that we do. And the special thing about it, it doesn't accept text-based source code, but it accepts tokenized source code. And we will look into the details and why is this of advantage in the setup that we're looking at. And then we do some summary and we have probably time for question and answers. Our set, we want to understand the general foundation of computation. So how small can it be looking at fun-human architecture and find out what is the essential really. And with a FOSS background, especially we want to know about the basic principles of FOSS. So what can be left out? There's an international standard. And of course you look at this following the quote from the little prince, take away what is not necessary and then you'll find perfection. And so we want to go there, make things smaller and have a sound basis and then let things grow again. So we want by this basis of a new modern FOSS. And I think about this morning's talks. So even a poem language or XP that we just saw could be implemented not just on LLVM, but on our basis. And so that's probably a nice thing. So within the new synthesis we follow certain guidelines. So we want to express most of the things in FOSS. And if you think about it, it's a high level language and you can express function applications and you can define data structures and so on. So we try to express as much as we can in FOSS. And we did this also with a cooperative multitasker that is normally supposed to be written in some low level assembly language for the task transfers. So this is also done in FOSS. We strive to get some bootstrapable things. And one of the languages is bootstrapable and very nice. All should be completely transparent. So you could talk to us and I'll say in two hours I can explain what's going on. If you have some FOSS background, a computer science background, and then you can look at all the source code that we have, which is quite a small amount of source code and you can understand what's going on. So it's completely transparent for you. Everything is accessible for you and it's simple to understand. So we're looking for simplicity. And for this we also look at analogy to biological things. For example, like how DNA is replicating and we're thinking about this. And seed FOSS, the name, goes into the area of botanics, of course. So something is a small seed and then it grows and we will see how it grows. The technique that we use is disaggregation. So we see this complex systems. We try to dissect it and find the principles in isolation. And then we reassemble these in an appropriate way afterwards. So, and on that way we build a family of minimalistic stack-based languages. And I have a slide that compares the two that are in the title of this talk. That's pre-FOSS and seed FOSS. And pre-FOSS was the initial attempt. And pre-SES, it's not really a FOSS because it says so many limitations. And you can see maybe as a key characteristics, the lines of code that you need to express this is 500 lines with pre-FOSS and roughly the same for the seed FOSS. So they are very small languages. And I'm not talking compiling to LLVM or some abstract machine. This is for the 386 machine code interface which spits out assembly code. And then there is an assembler. The other key feature maybe is the number of primitives. So the pre-FOSS has 13 primitives. And this means many features are missing like memory. It doesn't have addressable memory. It has to do all on the two stacks, which one is for parameter passing and the other one is for function called procedure return addresses. And because of this, if you want to do string handling, you have to do this all on the stacks, not in memory. So there are no memory representation of strings. You put them character by character on the stack and you deal with this, which you can assume is not very comfortable, but it works. And you have recursive functions in all of them. Also pre-FOSS doesn't have any control structures. The only thing is that you have procedure call with possibly tail recursion, elimination, and a conditional exit. And then you are up to formulate whatever programs you want. Both are during complete, so you can actually do this. And it turned out pre-FOSS is too simple, actually, to be the seed that we can grow everything out of it. I tried this and then within the discussion we said, okay, no, it's not worth it. But it's suitable to build the next FOSS system and that is seedFOSS. And seedFOSS now has memory, it has memory operators. It has some more primitives, mainly for memory and, yeah, I think it's mainly memory and some other things. And it's only a little bit more in size. It has conditional, so we have branching instructions as well, right? And so, yeah, so that's mainly it. And if you look at the data types, then pre-FOSS can only handle characters and integers and you build up all the structures on the stack. And of course, if you have memory, you want to address the memory. You also have addresses. Right, so let's come to the ICE concept. That's something that in the talk of Charles Moore, if you listen to him carefully in 1999 and I revised the YouTube videos that have been made at that time and I came up with, ah, right, ICE is what we're actually doing. That makes FOSS and other languages very exciting and, yeah, the property is we have an interpreter that can take commands and work on them. We have a compiler that can take text and create code and then we can even execute at arbitrary times things that we just defined. Yeah, and FOSS has this property, but other languages like LISP has this property. You do a function definition next time you call it. In FOSS, you define a word next time you call it. And you can even, during compilation, you can go ahead and switch between execution and interpretation. So that's quite nice. Small example, I can define a function definition erase, which goes and initialize some memory with zero. Then I can interpret, define some constant buffer with an appropriate size and then I can execute the definition that I just defined in there and this will execute at compile time, when I process the file and compile it. So let's have a look at CFOSS. The great thing about CFOSS that it accepts tokenized source code and this means it doesn't have, need to have a parser or whatever to analyze text, so that's just great. It's about 550 lines of code and you can extend it by doing function definitions. It could be recursive functions, so that's really easy and because it follows the ICE principle like all the languages that we do, it has a compiler that compiles definitions and interpreters that can execute definitions even during compilation. So that's quite nice and it's intended for building applications and one of these applications is actually a full featured interactive force system with a redevelopment loop, which is called text interpreter in the force terminology and we have I386 and AMD64 implementation right now but I experimented with the C back end as well as some symbolic back end so you can stuff it into a list system and to get some execution. So here's the course slide that shows what it is. There's something that is created with preforce that is called the C4 bed, think of flower bed, the also the botanic analogy and that's the small core 550 lines of code, 2K of memory and this is 32 beds so about 500 bytes is just the initialization of the table so the code is really small, it's 31 assembly primitives and then some amount of additional things. And then you have three levels, the text based source code at the top, tokenized source code in the middle and then the seed force bed on the growing seed force system below. Also we have of course operating system hardware support that is necessary to do some IO or whatever if you have an IOT device to access the hardware. And so if you have source code of your application, it first will be tokenized and then this token stream will be fed into the seed force bed and it will be extended but still it can do ICE, it can interpret things, it can compile things and it can execute things on the flight during compilation. The virtual machine that is about this looks like this, two stacks, one for parameter parsing, one for return stacks and instead of a parser it just has a symbol table. The names of functions are tokenized into function numbers and so in order to know where a function actually starts you just have an index access into the token table. The token table just captures the start addresses of the functions and if you appear to see, okay there's function 3B, actually coming, then you can go ahead and look up what it's starting address and you can compile a call to that property. So we have data memory and code memory to do this and several pointers that mark the free areas of this. So that's a quite simple architecture and here are the seed force bed words, I don't want to go into details of all of them but the two interesting things for the ICE concept are the interpreter and the compiler and what does the interpreter do? It accepts a token from the input stream and then it executes whatever function is associated with that number. It looks up in the table, finds the start address and then jumps to that, does a supproutine call and then it does interpreter again. So actually this is an endless loop because we have tail interpreter, it's tail recursive so it will not spill up the returns, they go whatever. The compiler will go accept the token or maybe it's a zero, then we exit the compiler loop, go back to the interpreter loop, maybe it's a lid and then we'll do some stuff with the literal but in the end if it's not a lid then it will just go ahead and compile a reference to the appropriate function and then it's also looped. So the compiler is in a loop until it finds a zero and the token interpreter will just go ahead and execute things. So we have source code, there where we look at the source code and we see here some, this is the hello world example for Seatforce. So we just emit things and we find in the tokenize thing also the string hello, we won't go into detail here very much. We can have a function definition increment the top element on the stack that is like this and then we can invoke this already here. So again we have interpret, compile and execute of things and if you look carefully on the previous slide the next token in the sequence would be 3B and Tata here is the 3B that is the invocation of the, that is the tokenized of this which will reside in the invocation in the compiler. So and that's the output of course and so where is the ICE principle now being applied really? That's when we have control structures. Control structures like begin until need to be compiled into conditional branches. Yeah, and yeah, in the end. So begin, the tokenizer takes function calls and makes single tokens out of it and there are also macros that expand to sequences of tokens and so begin expands to the sequence by here compiler which means exit the compiler, do something in interpret mode and then restart the compiler and until expands to the sequence question branch by, compiler which means compile branch then leave the compiler and compile the appropriate address and then restart the compiler. And so if we look at the tokenization then we see begin is 0, 1, a, 2, 4 and until will be compiled or tokenized to 15, 0, 0, 20, 24. And if we run this then that's it. Right, so seed forth grows. You just feed the seed forth bed, plan new things in there and we did lots of experiments with this and so we have dynamic memory and many, many things like exceptions and it cooperated by the task and closure like things and so on that you can build all on top of this and that's a full feature for system that I already talked about called seed forth interactive. You can all look up this up on the pre-force and this is a GitHub page and yeah, that's mainly it. So we want to extend this further and if you're interested come and get in contact with me so we can talk about this. So new targets, especially IOD targets are on the way and new synthesis the book and yeah, thank you very much for listening and I'm happy to answer your questions. Thank you. Can the next speaker come? So I guess as you showed the fourth source code of the interpretive word and the compiler word. Yes. But there are also primitives in seed forth itself written in assembly. Yes, yes. So pre-force can actually take code words and colon definitions and it will convert this to appropriate assembly language in the setup that we currently have and then you use the platform assembler to create the executable in the end. Yeah, so it's these 31 primitives written in assembler and then about 20 things among these compiler and interpreter to actually make this ice capability available. Okay, thank you very much. Any more questions? Yeah. I think you support this system to a new section but you have to only rewrite pre-force or you have to do it as it sounds. Yeah, actually you don't need to rewrite pre-force because it's used to do the seed-force. It can run on the host system but you need to rewrite the 31 primitives in seed-force and the estimate time because they are really, really simple like moving here and there. So you have half a day for a new platform so you can start reading the menu in the morning and in the evening you have a seed-force-bed system running and all above is just machine independent. You can just load it on top and it feels fast enough to work you would think a small set of primitives would slow it down dramatically. No, that's not the case. The experience is it's really fine, good to use and high-speed. Okay. Anyone? Yeah. So, Scott, this text please. How does it tokenize? There's a force program right now that does the tokenization and one of the tasks you might have seen on the slide is to rewrite the tokenizer in seed-force itself. It's already, I already have a version in seed-force interactive, the extended one, but we want to have it in seed-force itself and then so everything is self-contained and it's not strapping, it's there, everything transparent, everything available to you, no hidden things. Yeah. Okay, thank you very much. Ah, the mic. Thank you.
 Yeah, okay.  Hello, welcome.  Thank you very much for joining.  I will talk about FOSS and some experiments that we did with FOSS.  So my first question is who has heard about FOSS?  Okay, who has written a FOSS program?  Okay, I see.  So I try to be with a terminology close to normal computer science terminology,  because FOSS has its own kind of language I try to be as understandable as possible.  I will talk about the new synthesis.  It's a project that's ongoing and we try to understand the essentials of computation  and find minimalistic ways to realize things and build a basis of computation.  And for this we build a family of FOSS-like languages with restrictions and certain properties.  I will go then and talk about the ICE concept.  I think most of you wouldn't have heard about this before, but it's about 20 years ago  that Charles Moore, the inventor of FOSS, proposed the ICE concept.  So we will look at this and see that other programming languages have this as well.  And today I will focus on C-FOSS, which is one of these languages in the family of things that we do.  And the special thing about it, it doesn't accept text-based source code,  but it accepts tokenized source code.  And we will look into the details and why is this of advantage in the setup that we're looking at.  And then we do some summary and we have probably time for question and answers.  Our set, we want to understand the general foundation of computation.  So how small can it be looking at fun-human architecture and find out what is the essential really.  And with a FOSS background, especially we want to know about the basic principles of FOSS.  So what can be left out? There's an international standard.  And of course you look at this following the quote from the little prince,  take away what is not necessary and then you'll find perfection.  And so we want to go there, make things smaller and have a sound basis  and then let things grow again.  So we want by this basis of a new modern FOSS.  And I think about this morning's talks.  So even a poem language or XP that we just saw could be implemented not just on LLVM,  but on our basis.  And so that's probably a nice thing.  So within the new synthesis we follow certain guidelines.  So we want to express most of the things in FOSS.  And if you think about it, it's a high level language and you can express function applications  and you can define data structures and so on.  So we try to express as much as we can in FOSS.  And we did this also with a cooperative multitasker that is normally supposed to be written  in some low level assembly language for the task transfers.  So this is also done in FOSS.  We strive to get some bootstrapable things.  And one of the languages is bootstrapable and very nice.  All should be completely transparent.  So you could talk to us and I'll say in two hours I can explain what's going on.  If you have some FOSS background, a computer science background,  and then you can look at all the source code that we have,  which is quite a small amount of source code and you can understand what's going on.  So it's completely transparent for you.  Everything is accessible for you and it's simple to understand.  So we're looking for simplicity.  And for this we also look at analogy to biological things.  For example, like how DNA is replicating and we're thinking about this.  And seed FOSS, the name, goes into the area of botanics, of course.  So something is a small seed and then it grows and we will see how it grows.  The technique that we use is disaggregation.  So we see this complex systems.  We try to dissect it and find the principles in isolation.  And then we reassemble these in an appropriate way afterwards.  So, and on that way we build a family of minimalistic stack-based languages.  And I have a slide that compares the two that are in the title of this talk.  That's pre-FOSS and seed FOSS.  And pre-FOSS was the initial attempt.  And pre-SES, it's not really a FOSS because it says so many limitations.  And you can see maybe as a key characteristics,  the lines of code that you need to express this is 500 lines with pre-FOSS  and roughly the same for the seed FOSS.  So they are very small languages.  And I'm not talking compiling to LLVM or some abstract machine.  This is for the 386 machine code interface which spits out assembly code.  And then there is an assembler.  The other key feature maybe is the number of primitives.  So the pre-FOSS has 13 primitives.  And this means many features are missing like memory.  It doesn't have addressable memory.  It has to do all on the two stacks, which one is for parameter passing  and the other one is for function called procedure return addresses.  And because of this, if you want to do string handling,  you have to do this all on the stacks, not in memory.  So there are no memory representation of strings.  You put them character by character on the stack and you deal with this,  which you can assume is not very comfortable, but it works.  And you have recursive functions in all of them.  Also pre-FOSS doesn't have any control structures.  The only thing is that you have procedure call with possibly tail recursion,  elimination, and a conditional exit.  And then you are up to formulate whatever programs you want.  Both are during complete, so you can actually do this.  And it turned out pre-FOSS is too simple, actually,  to be the seed that we can grow everything out of it.  I tried this and then within the discussion we said,  okay, no, it's not worth it.  But it's suitable to build the next FOSS system and that is seedFOSS.  And seedFOSS now has memory, it has memory operators.  It has some more primitives, mainly for memory and, yeah,  I think it's mainly memory and some other things.  And it's only a little bit more in size.  It has conditional, so we have branching instructions as well, right?  And so, yeah, so that's mainly it.  And if you look at the data types, then pre-FOSS can only handle characters  and integers and you build up all the structures on the stack.  And of course, if you have memory, you want to address the memory.  You also have addresses.  Right, so let's come to the ICE concept.  That's something that in the talk of Charles Moore,  if you listen to him carefully in 1999 and I revised the YouTube videos  that have been made at that time and I came up with,  ah, right, ICE is what we're actually doing.  That makes FOSS and other languages very exciting  and, yeah, the property is we have an interpreter  that can take commands and work on them.  We have a compiler that can take text and create code  and then we can even execute at arbitrary times things that we just defined.  Yeah, and FOSS has this property, but other languages like LISP has this property.  You do a function definition next time you call it.  In FOSS, you define a word next time you call it.  And you can even, during compilation, you can go ahead  and switch between execution and interpretation.  So that's quite nice.  Small example, I can define a function definition erase,  which goes and initialize some memory with zero.  Then I can interpret, define some constant buffer  with an appropriate size and then I can execute the definition  that I just defined in there and this will execute at compile time,  when I process the file and compile it.  So let's have a look at CFOSS.  The great thing about CFOSS that it accepts tokenized source code  and this means it doesn't have, need to have a parser or whatever  to analyze text, so that's just great.  It's about 550 lines of code and you can extend it by doing function definitions.  It could be recursive functions, so that's really easy  and because it follows the ICE principle like all the languages that we do,  it has a compiler that compiles definitions and interpreters  that can execute definitions even during compilation.  So that's quite nice and it's intended for building applications  and one of these applications is actually a full featured interactive  force system with a redevelopment loop,  which is called text interpreter in the force terminology  and we have I386 and AMD64 implementation right now  but I experimented with the C back end as well as some symbolic back end  so you can stuff it into a list system and to get some execution.  So here's the course slide that shows what it is.  There's something that is created with preforce that is called the C4 bed,  think of flower bed, the also the botanic analogy  and that's the small core 550 lines of code, 2K of memory  and this is 32 beds so about 500 bytes is just the initialization of the table  so the code is really small, it's 31 assembly primitives  and then some amount of additional things.  And then you have three levels, the text based source code at the top,  tokenized source code in the middle and then the seed force bed  on the growing seed force system below.  Also we have of course operating system hardware support  that is necessary to do some IO or whatever if you have an IOT device  to access the hardware.  And so if you have source code of your application, it first will be tokenized  and then this token stream will be fed into the seed force bed  and it will be extended but still it can do ICE,  it can interpret things, it can compile things  and it can execute things on the flight during compilation.  The virtual machine that is about this looks like this,  two stacks, one for parameter parsing, one for return stacks  and instead of a parser it just has a symbol table.  The names of functions are tokenized into function numbers  and so in order to know where a function actually starts  you just have an index access into the token table.  The token table just captures the start addresses of the functions  and if you appear to see, okay there's function 3B,  actually coming, then you can go ahead and look up what it's starting address  and you can compile a call to that property.  So we have data memory and code memory to do this  and several pointers that mark the free areas of this.  So that's a quite simple architecture  and here are the seed force bed words,  I don't want to go into details of all of them  but the two interesting things for the ICE concept  are the interpreter and the compiler  and what does the interpreter do?  It accepts a token from the input stream  and then it executes whatever function is associated with that number.  It looks up in the table, finds the start address  and then jumps to that, does a supproutine call  and then it does interpreter again.  So actually this is an endless loop  because we have tail interpreter, it's tail recursive  so it will not spill up the returns, they go whatever.  The compiler will go accept the token  or maybe it's a zero, then we exit the compiler loop,  go back to the interpreter loop,  maybe it's a lid and then we'll do some stuff with the literal  but in the end if it's not a lid then it will just go ahead  and compile a reference to the appropriate function  and then it's also looped.  So the compiler is in a loop until it finds a zero  and the token interpreter will just go ahead and execute things.  So we have source code, there where we look at the source code  and we see here some, this is the hello world example for Seatforce.  So we just emit things and we find in the tokenize thing  also the string hello, we won't go into detail here very much.  We can have a function definition  increment the top element on the stack that is like this  and then we can invoke this already here.  So again we have interpret, compile and execute of things  and if you look carefully on the previous slide  the next token in the sequence would be 3B  and Tata here is the 3B that is the invocation  of the, that is the tokenized of this  which will reside in the invocation in the compiler.  So and that's the output of course  and so where is the ICE principle now being applied really?  That's when we have control structures.  Control structures like begin until need to be  compiled into conditional branches.  Yeah, and yeah, in the end.  So begin, the tokenizer takes function calls  and makes single tokens out of it  and there are also macros that expand to sequences of tokens  and so begin expands to the sequence by here compiler  which means exit the compiler, do something  in interpret mode and then restart the compiler  and until expands to the sequence  question branch by, compiler which means compile branch  then leave the compiler and compile the appropriate address  and then restart the compiler.  And so if we look at the tokenization  then we see begin is 0, 1, a, 2, 4  and until will be compiled or tokenized to 15, 0, 0, 20, 24.  And if we run this then that's it.  Right, so seed forth grows.  You just feed the seed forth bed,  plan new things in there and we did lots of experiments  with this and so we have dynamic memory  and many, many things like exceptions  and it cooperated by the task and closure like things  and so on that you can build all on top of this  and that's a full feature for system that I already talked about  called seed forth interactive.  You can all look up this up on the pre-force  and this is a GitHub page and yeah, that's mainly it.  So we want to extend this further  and if you're interested come and get in contact with me  so we can talk about this.  So new targets, especially IOD targets  are on the way and new synthesis the book  and yeah, thank you very much for listening  and I'm happy to answer your questions.  Thank you.  Can the next speaker come?  So I guess as you showed the fourth source code  of the interpretive word and the compiler word.  Yes.  But there are also primitives in seed forth itself  written in assembly.  Yes, yes.  So pre-force can actually take code words  and colon definitions and it will convert this  to appropriate assembly language  in the setup that we currently have  and then you use the platform assembler  to create the executable in the end.  Yeah, so it's these 31 primitives written in assembler  and then about 20 things among these compiler and interpreter  to actually make this ice capability available.  Okay, thank you very much.  Any more questions?  Yeah.  I think you support this system to a new section  but you have to only rewrite pre-force  or you have to do it as it sounds.  Yeah, actually you don't need to rewrite pre-force  because it's used to do the seed-force.  It can run on the host system  but you need to rewrite the 31 primitives in seed-force  and the estimate time because they are really, really simple  like moving here and there.  So you have half a day for a new platform  so you can start reading the menu in the morning  and in the evening you have a seed-force-bed system running  and all above is just machine independent.  You can just load it on top  and it feels fast enough to work  you would think a small set of primitives  would slow it down dramatically.  No, that's not the case.  The experience is it's really fine, good to use  and high-speed.  Okay. Anyone?  Yeah.  So, Scott, this text please.  How does it tokenize?  There's a force program right now that does the tokenization  and one of the tasks you might have seen on the slide  is to rewrite the tokenizer in seed-force itself.  It's already, I already have a version in seed-force interactive,  the extended one, but we want to have it in seed-force itself  and then so everything is self-contained  and it's not strapping, it's there, everything transparent,  everything available to you, no hidden things.  Yeah.  Okay, thank you very much.  Ah, the mic.  Thank you.
forth_new_synthesis_0_155.png forth_new_synthesis_156_311.png forth_new_synthesis_312_359.png forth_new_synthesis_360_407.png forth_new_synthesis_408_2315.png forth_new_synthesis_2316_2951.png forth_new_synthesis_2952_24767.png forth_new_synthesis_24768_25283.png forth_new_synthesis_25284_25499.png forth_new_synthesis_25500_26075.png forth_new_synthesis_26076_26159.png forth_new_synthesis_26160_27119.png forth_new_synthesis_27120_27239.png forth_new_synthesis_27240_28811.png forth_new_synthesis_28812_29051.png forth_new_synthesis_29052_29231.png forth_new_synthesis_29232_29387.png