[vhdl-200x] A compromise about modular type, boolean operations, integers...

From: <whygee@f-cpu.org>
Date: Wed Oct 22 2014 - 12:11:15 PDT
Hello again.

While discussing off-list, I listed the pros and cons of the 2 
approaches
discussed so far :

  * direct support by the integer type :
      - fast and easy to develop, maybe a few hundreds of lines
          of source code added to a simulator like GHDL (I don't
         know for the big professionnal software but it is a small
         incremental addition). A few days of coding, not much more
         to test, fast to deliver.
      - the range can create problems, we don't even know how many bits
         are handled ("at least 31, most likely 32, maybe 64" ?)

  * the new "modular" type
      - solves all the range problems, clean user code thanks to
          the masks and wrap-around performed under the hood.
      - introducing a new type means an order of magnitude more work,
          which is even slower because of all the legacy code and 
decades-old
          coding habits... So it's much less likely to appear and be used
          in a decent timeframe.

Then it struck me.
I don't know if this was mentioned before but the modular system works
almost like the 'range system. In fact, it is very similar, and it 
differs
only by wrapping around instead of trapping. So my compromise proposal
requires two simultaneous, low-to-medium complexity modifications :

  A) Let the integer type support 
not/and/or/xor/nand/nor/xnor/sll/sla/srl/sra/rol/ror
      just as it supports +, - etc. Eventually issue a warning that the 
user
      is shooting itself in the foot because the data size is not 
portable.

  B) Create a new behaviour (not type) by reusing all the code of 
"range".
      call it "modulo" or "modular" instead of "range", and when there is 
overflow,
      instead of issuing an error, wrap around. This is just a fork of an
      existing core feature of the language.

These two things, combined, should bring all the required safety and 
features
while keeping the total overhead (size, work, time, acceptance) low.
It's also "future proof" since it would not require a rewrite when
"universal integers" are implemented.


I suppose that inheritance of the range system means that modulo
must support lower bounds that are not zero, but we can decide 
otherwise.


Did I miss another caveat ?


YG

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Wed Oct 22 12:12:57 2014

This archive was generated by hypermail 2.1.8 : Wed Oct 22 2014 - 12:13:47 PDT