High level design plans

Performance

• C generation almost acceptable (faster vtable init left)
• Python is slow. Some alternative paths for acceleration, need to pick one:
  • pypy: Works already, limited wins, expensive startup. Can be accelerated by static type annotations? Compile server?
  • cython: haven't looked into this, incremental steps
  • reimplement parts in rust? Probably pays off iff we eventually re-implement large parts of dmlc in rust
• Develop DML code generator practices for avoiding huge banks
  • Dynamic register_view
• Offer hands-on help to SSM and PSG infra
  • proactively?

Coroutines

Allows for conveniently writing asynchronous sequential logic, a better alternative to state machines. For more information, see this paper

• hooks/channels (after on hooks)
• immediate after
• scoping (e.g. local variable invalidation within async methods)

Conditional imports

• may come with a larger loosening of order dependency rules for early evaluated expressions, i.e., early cross-obj param refs are ok if param dependency graph doesn't have cycles

Dynamic objects

There are requests to dynamically (at initialization time) determine the device, bank, register and field definitions. Two options:

1. Truly dynamic objects, e.g. instantiation-time config of array sizes
2. Optionally hidden elements, e.g. disabled registers

• dynamic ports are problematic, port arrays can't be port objects
• registers: compile-time overlap checks not possible, must allow mutually exclusive regs with overlap. Also need dynamic offsets (even sizes?).
• dynamic register_view
  • two kinds of disabled registers: flexible instantiation-time config (overlapping, dynamic offset) visible in register_view; run-time toggle is a different use case, should not show up in register_view.
• Peter's idea on "template classes"
  • essentially: instead of producing initialize_DEVNAME(void) that is automatically called, produce initialize_DEVNAME(const char *classname, int arg1, int arg2, ...) and expose this function to Python, for anyone to call
  • E.g., add compiler arg to define arglist of the initialize function, must be names of typed params in the device obj
  • can't rely as much on global variables, e.g. vtable pointers
  • Such params are inaccessible from indep methods, including shared indep methods (unless we employ unholy trickery like generating trampolines in run-time).
  • probably need a new level of independence between indep and non-indep
  • Alternative easier hack: static vars into separate C file, --split-c-file-style; parameterize by multiple static linking
    • easier but costs mem

RAII

Avoid the need for explicit allocation by supporting automatic destruction when variables go out of scope. Exact

• primitive types (strings and data blobs)
  • Includes RAII semantics for expressions like "x" + "y".
  • Unclear relation between RAII string type and const char * in type system; likely need implicit conversions.
• vectors

Simulator Agnosticism

• Attribute objects are oriented around the Simics-specific attr_value_t type. This presents the largest challenge so far for DML to become simulator agnostic, and must eventually be addressed. The DML team hasn't come to a consensus about what approach we should take.
  • Erik wants all attributes to work through a serialized_t type. Values of serializable DML types can be converted to and from this type via serialize/deserialize primitives. This means serialized representations of types are external and simulator-specific.
    • The fact serialized representation is external has unavoidable cons. It incurs a general obligation for backwards compatibility re. serialized representations beyond simple backwards checkpoint compatibility.
    • This approach also means fewer tools are available for simulator-agnostic code:
      • simulator-agnistic union deserialization must choose between messy try/catch chain and simulator-dependent predicates like is_integer
      • The type-strings we use today for strict type enforcement remains a simulator-dependent feature
      • there are open questions on how lists should be handled
  • Love wants attributes to work through a simulator-agnostic attr_value_t-like interface. Think, crib the concept of JSON — specifically, a specification of primitive (bools, ints, strings, etc.) and composite values (lists, dicts) — and add type enforcement. The way this simulator-agnostic attribute type is mapped to simulator interfaces are simulator-specific and external.
    • This allows people to handle simulator-device interaction in very much the same way Simics allows today.
    • Serializable types are mapped to the simulator-agnostic attribute value type in an internal way.
    • The biggest question lies in how we design the simulator-agnostic type such that we can reasonably expect any simulator to be able to map it to its own interface. Love's opinion is to go the JSON route of keeping the primitive components of the attribute type specification simple, and then force implementations to deal with the specification as good as they can.
      • A related question is how type enforcement can be designed such that it can be mapped to the interface of any arbitrary simulator.

dml-gdb

Update to add proper awareness of newer DML constructs

• Template hierarchy
• Shared methods

Continuous flow of manageable hot potatoes

• easy: hot potatoes form a heap, so extract-min.
• harder to prioritize against longer-term tasks?

Cleanup runs

• occasionally batch-fix easy issues, similar to doc-week?

Language Server and Clients

Being developed over at https://github.com/intel-innersource/applications.simulators.simics.base.dml-lang-server and https://github.com/intel-innersource/applications.simulators.simics.base.dml-vscode-client

• How to properly synchronize changes in DML with the server?
• Is there a way to unify the definition of the syntax between DMLC and the server
• More client services (notably, emacs and potentially eclipse)