Author |
Message |
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
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 |
|
|
Mac Buster
Retired
Joined: 03 Aug 2003 22:37 Posts: 1474 Location: Moscow
|
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 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
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 |
|
|
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.
|
27 Jan 2009 09:43 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
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 |
|
|
Mac Buster
Retired
Joined: 03 Aug 2003 22:37 Posts: 1474 Location: Moscow
|
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 |
|
|
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.
|
28 Jan 2009 02:19 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
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 |
|
|
eudoxie
Maniac
Joined: 17 Sep 2012 13:36 Posts: 277 Location: 81.170.128.52
|
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 |
|
|
Shaos
Admin
Joined: 08 Jan 2003 23:22 Posts: 22530 Location: Silicon Valley
|
moving up
|
10 Nov 2012 08:56 |
|
|