RE: [vhdl-200x] RE: Modular types

From: <>
Date: Thu Jul 24 2014 - 05:33:26 PDT
Le 2014-07-24 14:03, Martin.J Thompson a écrit :
> In general the answer to "why not?" is that it takes effort to both
> specify and implement the behaviour.  If said behaviour is not going
> to be used, then that effort would be better spent on more useful
> functionality.

I understand.

Now, by the same logic, the early VHDL specifications didn't deem
some basic features as "worthy" and this puts us today in this 
the questions of "how should we handle booleans" remains.

VHDL does not strictly forbid bool/shift on integers, but it does
not allow it either. And that's the trouble : somebody "not seeing any 
can prevent others from benefitting from very basic features that other
languages enjoy (among other things).

At this moment, somebody else is creating a new "toy CPU" for teaching
logic design in university. The first things that he does, like most 
before him, is to define and implement add/sub, and/or/xor and 

He does this in Verilog.
Now let's do this in VHDL : sure, data would be in std_logic_vector.
Which is awesome for low-level simulations. But for system-level,
it's slow.

Add/sub for integers in VHDL : check.
We have ranges and tons of wonderful features.
yet some binary instructions are second-class operators.

So to expand my "why not",
  - it's there, has always been and will always be.
      Name a general purpose CPU without it.
  - if you can add stuff, then you should be able to and/or/xor/shift it.
       because that's how it's done internally in a add/sub instruction 
  - it's useful, it's fast (only one CPU cycle) and it's lightweight, 
it's well defined
      and most people understand what it is, what it does and how.
  - it's about time.
  - the modular type makes the bool/shift operator "safe" (at least of 
     contrary to the integer type that probably made the early 
implementors uncomfortable.

Now, i'm totally lost about how it should be implemented or specified in 
the LRM.
I just know it should be totally transparent on the VHDL source side.

> Martin

This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Thu Jul 24 05:33:49 2014

This archive was generated by hypermail 2.1.8 : Thu Jul 24 2014 - 05:34:06 PDT