Le 2014-10-26 06:43, tgingold@free.fr a écrit : >> subtype a : integer range 123 to 456; -- existing syntax > Sorry, but this is not the existing syntax :-( Yup, sorry, tired... According to LRM section 4.2 : subtype subtype_name is base_type range range_constraint; so let's substitute the ":" with "is": subtype a is integer range 123 to 456; >> subtype b : integer modular 789 to 101112; -- new syntax >> subtype c : integer saturated 131415 to 161618; -- new syntax subtype b is integer modular 789 to 101112; -- new syntax subtype c is integer saturated 131415 to 161618; -- new syntax > a subtype does not define a type. sure. > There is no implicit operators declared by a subtype. AFAIK, right. > So the semantic of operators for these modular/saturated subtypes > is the same as the semantic for the existing integer types operators. So far, i'm ok. What change do you expect ? > As a consequence, the result of 'x + y + z' may be not the > same as the result of 't = x + y; t + x'. I suppose you intended to write 't = x + y; t + z'. I don't see where you define the operands either, so i don't see your point. Anyway, writing such expressions leaves the door open to precedence troubles. Parentheses are cheap these days, fortunately. > And I am sure this is a no-go. Personnally, I'm not trying to make something ambitious, but practical. I'm not trying to turn VHDL into a language for symbolic number theory. I just want the language to ease the burden of MODing certain results with the right modulus, automatically. What are you expecting from a modular feature ? You write that certain things are "no-go" but you don't explain why, I miss the context or intention. Can you elaborate ? > Tristan. Yann -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Sat Oct 25 23:20:51 2014
This archive was generated by hypermail 2.1.8 : Sat Oct 25 2014 - 23:21:14 PDT