About the assembly language used by the pep/nom system to compile and run scripts in the pep interpreter.
The nom system is a “self-hosting compiling” system but not just in the usual way that compilers can be self-hosting (that is: that the compiler for a language like java, go, dart, wren, lisp, forth can compile itself - once a bootstrap compiler has been created ), but it is self hosting on multiple levels.
That is a grandiose statement, and here is the explanation: The nom language (which runs on top of the pep machine ) is self-hosting because the nom compiler is written in nom. To update the compiler, we can modify compile.pss and then use it to compile itself as follows:
pep -f compile.pss compile.pss > asm.test.pp
Apart from being a neat trick it also makes maintaining the compiler simpler. But what is this asm.test.pp ? It is a “pep assembly” file and you can have a look at the gory details in the current assembler bumble.sf.net/books/pars/asm.pp Its probably a lot easier to understand that most assembly languages because the instruction names are a bit longer and it is also space indented (the nom compiler does the indenting)
The file bumble.sf.net/books/pars/asm.pp is the real compiler and if you delete it the pep interpreter will suddenly and unceremoniously stop working. This is because the asm.pp compiler is also self-hosting which means that when you type
pep -f gargle.compiler.pss -i "/*test gargle comment*/ "
The pep interpreter opens 'gargle.compiler.pss' (which would be a compiler for the amazing gargle language) and which is a nom script and then it uses asm.pp to compile this nom script into a ... pep assembly file. So now the pep interpreter has an assembly file called something like “script.pp” which it can load directly (into a Program object, which is just a series of Instruction objects). Once it has loaded the assembly file it runs the script using the input given to the -i switch.
So that is another level on which pep/nom is a self-hosting compiling system. But there is another:
pep -f tr/translate.go.pss tr/translate.go.pss > nom.to.golang.go
(this could be run from the pepnom base folder of the downloaded and unpacked pep/nom system)
The incantation above takes the nom script which translates nom scripts into the go language (googles successor to c/c++ ) and uses it to translate itself into “go” . All this can become a bit strange to think about. But it has a practical purpose: after compiling the go source code in “nom.to.golang.go” with something like
go build nom.to.golang.go
we have an executable go program which will translate nom scripts into go source code. This means that we can completely dispense with the pep interpreter, which may be a good thing since it is written in plain c with byte char characters and who knows what memory leaks and weird undiscoverable cbugs it may have hidden under the bonnet.
So this somewhat onanistic translation of nom translation scripts is another level at which the pep/nom system is a self-hosting compiling system.
As far as I know, there is no other language system which can do all this, and especially not for a language as simple and as (more or less) readable as nom .