Refining the rvm specification

[hrszpuk]

Specification is missing a lot of information.

Section Ideas

• [x] Architecture
  • [x] Overview
  • [x] Call Stack
  • [x] Instruction Buffer
  • [x] Registers
  • [x] Variable Pool
  • [x] Multi-threading
  • [x] Opcode Stream
  • [x] Dynamic Binary Loading
• [x] Instruction Set
  • [x] Overview
  • [x] Human-readable bytecode
  • [x] Bytecode format
  • [x] Macros
  • [x] Opcode
  • [x] Opcode format
  • [x] Code Block
  • [x] Stack Management
  • [x] Arithmetic and Logic
  • [x] Store/Load
  • [x] Type Conversions
  • [x] Control Flow
  • [x] Subroutines
  • [x] Data Block
  • [x] Constants
  • [x] Variables
  • [x] Structures
  • [x] Metadata Block
• [x] Code base
  • [x] Translation module: translates human readable bytecode to actual opcodes
  • [x] VM module: interprets opcodes
  • [x] Data Structures: Stack, Dictionary, Heap, Buffer

[Khhs167]

I'd like to suggest something like metadata, or just a "binary layout"

If we look at runtimes like the .NET CLI, the binaries all store where different functions, classes and values are stored. I believe this could be very important for anyone wishing to develop a language for RVM, plus it helps with debugging(since you can store stuff like variable locations in the metadata).

This could go hand-in-hand with assembly-style regions(splitting the code into multiple parts), where there's one region(maybe at the start), which just lists any symbols or other metadata we might need.

Not sure how to do it, but it would be useful.

[hrszpuk]

I'd like to suggest something like metadata, or just a "binary layout"

If we look at runtimes like the .NET CLI, the binaries all store where different functions, classes and values are stored. I believe this could be very important for anyone wishing to develop a language for RVM, plus it helps with debugging(since you can store stuff like variable locations in the metadata).

This could go hand-in-hand with assembly-style regions(splitting the code into multiple parts), where there's one region(maybe at the start), which just lists any symbols or other metadata we might need.

Not sure how to do it, but it would be useful. I was think about changing the layout to something similar to this:

.metadata
; ?

.extern printf

.data const x 14

.code push x push x add out push "Hello World" call printf halt

What do you think @Khhs167?

[hrszpuk]

Or I suppose making it similar to CIL external would be more like:

.extern stdio
.code
call [stdio]printf

[Khhs167]

It depends on what we want to achieve.

My general idea was something in the likes of(in my assembler style here ofc)

.META

.str "function_a" .const function_a ; Simple lookup table

.CODE

function_a:
    ; Whatever

With a macro we'd be able to do smth like

.export $1

; Expands to:

.META
.str "$1" .const $1

Ignore the style of code I wrote, the idea is what's important: Each binary lists its own symbols

Edit: Changed some wording.

[hrszpuk]

Yeah, you're right, each binary should list its own symbols if it wants to export them. This would make it way easier to actually read as well.

If this is for rvm files it could be similar to this (syntax-wise):

; <======== lib.rvmt
.meta
.const function "function"; exported here
; or .export function
; I do want macros (lisp-style), I should probably add them to the spec.

.code

begin function 
; function code here
end

; <======== main.rvmt
.meta
.extern "lib.rvmt" lib ; external library linked as "lib"

.code
call [lib]function 

They could be can be built together:

rvm build main.rvmt // rvmt is human readable bytecode which, when built, is convert to opcodes
rvm run main.rvm // vm runs the opcodes

edit: when built, everything is slammed into a single file (exported symbols are made available to main code)

[hrszpuk]

This is for importing during compilation, for importing during runtime I think something similar to the idea you proposed in the discussion thread would be better.

[Khhs167]

Sound good!

[Khhs167]

Oh and, before I forget... Should out really be kept in the spec?

It could just be made part of the standard library?

[hrszpuk]

Oh and, before I forget... Should out really be kept in the spec?

It could just be made part of the standard library?

Yeah it would probably be best to move all I/O into a standard library. I haven't really given much thought as to what the standard library will include, or how big the library will be.