nedoPC.org

Electronics hobbyists community established in 2002
Atom Feed | View unanswered posts | View active topics It is currently 28 Mar 2024 05:01



Reply to topic  [ 10 posts ] 
Abstract ternary machine 
Author Message
Maniac

Joined: 17 Sep 2012 13:36
Posts: 277
Location: 81.170.128.52
Reply with quote
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.


26 Jan 2009 12:24
Profile
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
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.


27 Jan 2009 01:23
Profile
Maniac

Joined: 17 Sep 2012 13:36
Posts: 277
Location: 81.170.128.52
Reply with quote
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.


27 Jan 2009 08:58
Profile
Reply with quote
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.


27 Jan 2009 09:43
Maniac

Joined: 17 Sep 2012 13:36
Posts: 277
Location: 81.170.128.52
Reply with quote
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.


27 Jan 2009 11:27
Profile
Retired

Joined: 03 Aug 2003 22:37
Posts: 1474
Location: Moscow
Reply with quote
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.


27 Jan 2009 22:46
Profile
Reply with quote
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.


28 Jan 2009 02:19
Maniac

Joined: 17 Sep 2012 13:36
Posts: 277
Location: 81.170.128.52
Reply with quote
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.


29 Jan 2009 08:21
Profile
Maniac

Joined: 17 Sep 2012 13:36
Posts: 277
Location: 81.170.128.52
Reply with quote
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:
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


30 Jan 2009 13:16
Profile
Admin
User avatar

Joined: 08 Jan 2003 23:22
Posts: 22409
Location: Silicon Valley
Reply with quote
Post 
moving up

_________________
:dj: https://mastodon.social/@Shaos


10 Nov 2012 08:56
Profile WWW
Display posts from previous:  Sort by  
Reply to topic   [ 10 posts ] 

Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group
Designed by ST Software.