Skip to content

Schemacode: mlog parametrization #330

@cardillan

Description

@cardillan

Mindcode supports program parameters. By adding a param section to the processor configuration, it would be possible to replace the built-in value of a program parameter with a new one:

    @micro-processor at (0, 0) processor
        mindcode = file "code.mnd"
        param
            UNIT_TYPE = @flare
            MAX_UNITS = 10
        end
    end
    @micro-processor at (0, 1) processor
        mindcode = file "code.mnd"
        param
            UNIT_TYPE = @mono
            MAX_UNITS = 8
        end
    end

This assumes the code.mnd declares these parameters, for example:

param UNIT_TYPE = @poly;
param MAX_UNITS = 5;

The replacement would be done on the generated mlog code: an instruction matching the set PARAM value would be searched in the code, and if found, the value in the first occurrence would be replaced with the value provided by the parameter. Comments and whitespace on the instruction line would be preserved.

As this gets done on the mlog code, the parameters may be applied whether the processor's code is provided as a mlog or a Mindcode source. In case of Mindcode, it would be required that the parameter is actually declared as a program parameter (the compiler will provide a list of existing program parameters). This makes the replacement relatively safe, assuming the parameter isn't manipulated by mlog blocks (which is inherently unsafe anyway).

On mlog, no real safety checks would be possible. If a matching instruction is found, it is replaced. It wouldn't be required that the instruction occurs at the beginning of the code.

Schemacode can already join code snippets, so technically, the code in the example could be easily replaced by this:

    @micro-processor at (0, 0) processor
        mindcode = """
            param UNIT_TYPE = @flare;
            param MAX_UNITS = 10;
        """ + file "code.mnd"
    end
    @micro-processor at (0, 1) processor
        mindcode = """
            param UNIT_TYPE = @mono;
            param MAX_UNITS = 8;
        """ + file "code.mnd"
    end

The new approach has two advantages:

  • The original file ("code.mnd") can be still compiled standalone, as the parameter definitions are included.
  • When building the schematics, the code.mnd file would be only compiled once. For large and complex schematics, this can significantly reduce compilation time.
  • For pure mlog, the advantages are similar: adding parameters as separate instructions by combining code snippets is possible, but makes developing and maintaining the mlog code more complex.

Theoretically, even more complex code replacements would be possible, up to something like sed. I don't see a compelling use-case for that, though. It would be most useful to replace link names in an mlog code, but Schemacode already gives the use a full control over link names. And if someone really wanted to incorporate sed into their build pipeline, it can already be done outside Mindcode/Schemacode by manipulating source files before passing them on to Schemacode.

Metadata

Metadata

Assignees

No one assigned

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions