Abstract ternary machine

[eudoxie]

I've been researching various abstract concepts in language and virtual machine design, and sort of have an idea for a highly abstract machine that is suitable for making higher level programming languages for.

Tunguska is very "down to earth" in that it seeks to be as close to an actual computer as possible. What I'm suggesting is to build the exact opposite. It would not emulate any sort of hardware, with much more limited "communication" with the outside world.

I'm thinking of a strict stack machine as opposed to a register machine like Tunguska, with a much smaller and more abstract instruction set that deals in concepts such as machine-level dynamically allocated stack frames, tagged memory cells (possibly with permissions). It would also use a vastly larger word size (3^18), which would allow opcodes to be entirely atomic. This together with self-contained code segments would make nearly any code automatically concurrent.

I'm considering a hard-coded object system like JVM has, but I'm not sure whether I like the idea or not. It makes the machine specifications more cluttered and harder to understand. I can't quite make up my mind on what sort of types to implement on a machine level, and I have a rather long list of ideas:

X Strictly typed objects (like Java)
X Weakly typed objects "duck typing" like lua or ruby
X Integers
X Floating point
X Linked lists (like LISP)
X Functions as types (e.g. closures)
etc.

If you have ideas as to why or why not any of these should be implemented on a machine level, please share your opinion.

I'm hoping with the recent advances in algorithms, it's possible to get it to run 20-30 times slower than C.

[Mac Buster]

At this approach speed is not very important. Do you remember once upon time we were discussing a machine which can store it's own configuration in an XML file and restore it while starting? You can do your stack machine as XML-configurable one.

[eudoxie]

I'm thinking that XML based configuration should be doable without any significant performance loss, if one uses XML to tell the program what symbols to load from a dynamic library.

[hemuman]

XML seems to be a good option.The Idea is great. so that way we will be building an xml interpreter as in concepts of browsers where for XML we have CSS. And according to CSS information XML is interpreted by the browser.

[eudoxie]

The problem with XML as I see it, is that it's nearly impossible to write a virtual machine with no assumptions on it's design. Will it be a register machine? Or an accumulator machine? Or a stack machine? Will it have stack frames? What of pages? Will the memory be continuous or dynamically allocated? What addresses will be legal? What does negative addresses mean? Will there be interrupts? Will there be exceptions? What about I/O? How long will the instructions be? What is the word size? Will there be a status register? When will the status register clear? And so forth.

So either you have to describe these features in XML (effectively leaving you with VHDL wrapped in XML) making the xml file thicker than the bible and the machine slower than the ENIAC; or the XML-machine will force some machine paradigm on you, defeating the purpose of describing it in XML in the first place.

I think a viable middle road would be using Java's class loader and reflection abilities and use XML to specify what classes to load and where. But Java really isn't my strong suit, so I don' think I would be able to do much good there.

[Mac Buster]

Yes, of course I don't mean defining all possible specs in XML file. Only some of them in current architecture, that could be changed by machine developer if he wants it.

[hemuman]

Hi eudoxie!

if we have some idea to work here please do not worry about the languages...I can work with many of today's programming languages (Perl,Python,Java,Ruby...) , what we really need is an Architecture. If you can work on that I can implement in desired language.

[eudoxie]

I still have philosophical difficulties with this approach. Naturally, many different architectures is a good thing, but they should each contribute something. A large number of similar architectures is probably more harmful than it is useful.

It makes no sense to open up for countless very similar but incompatible architectures. It would be impossible to build higher order tools like compilers if there are hundreds of different architectures to build against.

As I see it, it's probably a better idea to have a more democratic design process for the existing (and upcoming) architectures.

[eudoxie]

The issues with XML aside, I have a rough idea of what the language the stack machine would speak would look like. I've been thinking, and I like the idea of a machine that "thinks" in scopes on an assembly level. They can function as arrays, structs, closures, program flow, etc.

Code: Select all

2       ' Two static values
0       ' No dynamic values
CSC
        0       ' No static values
        0       ' No dynamic values
        CSC ; Create scope
          @[1:1]  ' Push previous scope, frame address 1
          1      ' Push 1
          ADD    ' Add
          [1:1]  ' Push address of previous scope, address 1
          STO    ' Store 1 in [1:1]
          @[1:1]  ' Push previous scope, frame address 1
          1       ' Select chanel 1
          IO      ' Print
        ESC ; End scope

        0       ' No static values
        0       ' No dynamic values
        CSC ; Create scope
          @[1:1] ' Push value of previous scope, frame address 1
          10     ' Push 10 
          CMP    ' Compare (result on stack)
        ESC

        WHILE    ' Execute the scope that is second on stack  while the scope first on stack pushes truth values when run
ESC
[-1:1]          ' Push address of scope on stack's variable 1 (second variable)
0               ' Set value
STO             ' Store

' Duplicate uppermost stack value (our new scope)
DUPL
' Run pushed scope twice
RUN     ' Prints 1,2,3,4,5,6,7,8,9,10
RUN     ' Prints nothing (1:1 is static)

HLT

[Shaos]

moving up