Add function definition, plus various other versatility improvements

[thecodewarrior]

• slices use half-open ranges, instead of [7:0], it's [8:0]. this means [0:0] is empty, not a 1-bit value. the void constant stands for 0[0:0]
• #include works inside the cpudef directive
• ExpressionValues carry a width, which allows dynamic instruction width
• if an instruction is passed a forward label reference and and it doesn't have a fixed width, its width will be guessed by passing a zero for the unknown values. if this guess isn't correct when passed the actual value, an error is thrown
• added syntax.txt file
• added basic vscode highlighting syntax
• added _insn_start/_insn_width/_insn_end variables, _insn_width and _insn_end are missing for instructions of variable width
• added a expression tree debug printout
• added the ability to use multiple tokens in a tokendef (''&'@ is a valid identifier, as is ram> and dat boi), and replaced the = from tokendefs with :
• added more symbol types: <-, =>, '
• replaced -> in previous syntaxes with =>, allowing <- and -> to be used in instructions. the other way around wouldn't work because <= is an operator.
• applied rustfmt
• replaced a number of ordinal enum associated values with named fields
• added functions, basically fleshing out the existing syntax used for assert() statements:

  #fun fun_name(arg, arg2) =>
  {
  0x001 @ arg1[8:0]
  }

[ProxyPlayerHD]

slices use half-open ranges, instead of [7:0], it's [8:0].

but why would you do this? HDLs like Verilog and VHDL also use [7:0] to define an 8 bit value. because like any sane programming languge and hardware itself bit widths are 0 indexed. you can't just change that randomly. people will rip their hair out over this. plus it would require everyone to rewrite their CPUs.

[thecodewarrior]

Fair enough, I’m not well versed in this stuff :P

I would prefer it would be zero-indexed internally, as that makes a lot of math a lot simpler and makes zero-width values (e.g. void) possible. I could make it just add one to the bound when parsing.

[thecodewarrior]

Unless I missed something in my changelog people will still have to fix their CPUs though due to two changes. Admittedly much simpler fixes though. Specifically the fact that tokendefs now use : instead of =, and that instruction definitions now use => instead of ->.

I briefly explain why I replaced -> with => in the original comment, but it stems from the fact that I thought it would be useful to have arrows in instructions. I can’t use <= and => since <= is a comparison operator and would screw up insn parsing, so I decided to use <- and ->, which would only be ambiguous in the case of foo < -bar, which I don’t foresee happening and is simple enough to fix. The problem with using thin arrows is that -> was already used to signal the end of an instruction definition, so I had to replace it with the unambiguous fat arrow =>.

[ProxyPlayerHD]

why would you need void values at all? and even then why not add a special case that is usually completely unused. [-1:0] or any negative value could be used to create a void or "0 width vlaue".

also to seperate actual instruction text from operants like { } -> => etc, why not have the instruction text that is supposed to be ingored in quotes? to tell the assembler that everything inside quotes just has to match what has been written in the assembler and otherwise ignores every command inside it

`"LD A -> "{dest} "=> MEM" => 0x0F @ dest[7:0]

[thecodewarrior]

So I'm getting back into rust after ages and I'm starting fresh. I pushed these changes into a functions-and-friends branch for anyone in the future that wants to see them.