Skip to content

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
    • Help
    • Submit feedback
    • Contribute to GitLab
  • Sign in
G
general-issue-tracker
  • Project
    • Project
    • Details
    • Activity
    • Releases
    • Cycle Analytics
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Charts
  • Issues 47
    • Issues 47
    • List
    • Board
    • Labels
    • Milestones
  • Merge Requests 0
    • Merge Requests 0
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Charts
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Graph
  • Charts
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
  • mu
  • general-issue-tracker
  • Issues
  • #35

Closed
Open
Opened Jun 22, 2015 by John Zhang@u5157779
  • Report abuse
  • New issue
Report abuse New issue

Alternative LISP-like Mu IR format

Created by: wks

Problem: Mu IR needs a parser, but constructing a parser is tedious. Parser generators pulls in additional dependencies.

Solution: Use a simplistic syntax based on LISP.

Example:

(typedef @i32 int 32)
(typedef @float float)
(typedef @void void)
(typedef @refvoid ref @void)
(typedef @foo struct @i32 @i64 @float @double @refvoid)

(funcsig @f_sig @i32 (@i32 @i32))

(const @FORTY_TWO @i32 42)
(const @DOUBLE_FORTY_TWO @double 42.0d)
(const @SOME_STRUCT_CONST @some_struct @const1 @const2 @const3)
(const @NULLREF @refvoid NULL)

(global @errno @i32)

(funcdecl @write @write_sig)

(funcdef @write @write_v1 @write_sig (%p0 %p1 %p2)
  (basic-block %entry
    (inst %a (ADD @i32 %p0 %p1))
    (inst %b (CALL @sig @callee (%arg1 %arg2 %arg3) (exc %nor %exc) (keepalive %v1 %v2 %v3)))
  )
  (basic-block %nor
    (inst _ (SUB @i32 %p0 %p2)) ; unnamed instruction
    (inst _ (BRANCH %exit))
  )
  (basic-block %exc
    (inst _ (TRAP @void))
  )
  (basic-block %exit
    (inst _ (@uvm.thread_exit)) ; COMMINST is no longer necessary because the syntax is already dynamic
  )
)

How would this benefit the Mu implementer? The parser can be written by hand in very few lines of code. This is convenient for languages that has less capabilities (such as C which does not handle complex type hierarchies easily).

How would this benefit client implementers? The code generator can be more typed (using structured nested lists), rather than constructing arbitrary strings (using string formatting).

Binary format? There can be a simpler and direct mapping between the text format and the binary format. For example, atoms can be encoded as a hash code, and a list can be encoded as a type, a length and a list of values. Mu spec no longer needs to define a text format and a binary format separately.

Problems?

Does not look like assembly.

May be less readable than the current text format without aggressive pretty-printing.

Extra validation should be performed by the parser. (Really? The Mu micro VM is not required to correct any errors. Any error is allowed to have undefined behaviours.)

Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
0
Labels
None
Assign labels
  • View project labels
Reference: mu/general-issue-tracker#35