Creating new operators

On Sat, 26 Jul 2008 06:04:01 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley
>>
>> It may be personal preference, but I find if-then-else MUCH easier to
>> read in somebody else's code.
>>
>> ?: does save a few of those precious characters though.
>>
>> - Brian
>
>The problem is not so much reading the code, but is writing.  I think
>in the terms of the logic, usually a schematic/block diagram.  Then I
>try to express that logic in the language. 

This may be a cheap shot, but I think it's telling that, even in the
presence of a clear text specification ...
>Example: A data mux controlled by the output of an AND of a signal and
>the output of a mux.
and a correct VHDL description...

>  BERTEn <=	'0' when BERTSel = '0' else
>		not SyncPOSSel when GenEn = '0' else
>		not GenPOSSel;

>Compare the two examples to this code...
>  BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;

... the one-line Verilog implementation is either wrong, or confusing to
several industry experts! (I don't know which; I'm definitely not cut
out for Verilog)

I don't believe this was a deliberate plot on Jonathan's or Mike's part
to diss Verilog, but YMMV.

>This is what I expect a concurrent statement to look like, not to
>mention that it represents exactly the image I had in my head and on
>the whiteboard, making it much easier to write.

If you mean the brevity rather than the form, I actually agree, though
as written I couldn't tell you what it does. (Rewritten with
parentheses, I could figure it out eventually)

But I don't see what's wrong with 

BERTEn <= BERTSel and ( not SyncPOSSel when GenEn = '1' 
                                       else not GenPOSSel);
which I believe does the same thing.

- Brian

On Mon, 28 Jul 2008 12:40:09 +0100, Brian Drummond
<brian_drummond@btconnect.com> wrote:

>On Sat, 26 Jul 2008 06:04:01 -0700 (PDT), rickman <gnuarm@gmail.com>
>wrote:

>>Compare the two examples to this code...
>>  BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>
>... the one-line Verilog implementation is either wrong, or confusing to
>several industry experts! (I don't know which; I'm definitely not cut
>out for Verilog)
>
>I don't believe this was a deliberate plot on Jonathan's or Mike's part
>to diss Verilog, but YMMV.

... double apology required; sorry Jonathan, re-reading the thread, I
see I took your name in vain here, and..

... it would of course be perfectly _possible_ to implement the same bug
in VHDL. It is my opinion that the "when" clause calls out to be
bracketed so it is less likely to happen, but that is merely opinion. 

Of course, someone who conditioned themselves to bracketing ?: clauses
would also have avoided the ambiguity. 

But I feel that VHDL's emphasis on expressing something precisely,
reduces the likelihood of getting it wrong; (worked in this case!) and
that saves time overall.

Yes,
>>  BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
is faster to write; but when you factor in the debugging time, which
comes out ahead?

- Brian

On Jul 28, 4:14 am, Colin Paul Gloster <Colin_Paul_Glos...@ACM.org>
wrote:

>
> I would prefer to use one tool which supports the language I am using
> instead of a preprocessor which supports some of it by replacing
> strings by other strings to be given to another tool which tries to
> cope with another part of the language.
>
> Would you suggest that someone who does not want to use such a
> preprocessor should write an entire extended language frontend
> (perhaps written by reusing code from a full proper BNF-based VHDL
> frontend)?

Mr. Rickman expressed concern from a language point of view in terms
of syntax more directly modeling his ideal representation  not being
present in VHDL, not whether or not he was willing to use a
preprocessor.

The BNF for VHDL 93 for instance, isn't semantically complete, nor is
it non-ambiguous.  You actually have to understand the language to
contemplate making changes to it, and the BNF isn't sufficient.  It
seems a bit overkill to start anew then replicate most of VHDL.

A preprocessor sufficient for Mr. Rickman's preferred concurrent
assignment statement form could easily be written in a small AWK or
Perl script, passing through elements of a source file not affected.
You'd probably be well served maintaining line count between the two
versions, making VHDL a bit more ugly.

You could also conceivably translate to your preferred syntax from
VHDL in an editor like emacs or joe, write in your preferred syntax
abstraction and store the file in VHDL.  It would be embarrassing to
stumble over understanding VHDL in printed form. The question is
whether or not someone else could read it comfortably if you did the
obverse and made the extended version normative.  The point being that
in Domain Specific Language, no two domains have perfect
intersections, and somewhere, someone is making a compromise.

The idea of using a preprocessor was meant as a gauge of how serious
Mr. Rickman was for his syntax, a way of actually implementing it
without breaking anything, using a method  shared with the first C++
implementation.

 --
=93Blindness can take many forms other than the inability to see.
Fanatics are often blinded in their thoughts. Leaders are often
blinded in their hearts.=94

On Jul 28, 7:40 am, Brian Drummond <brian_drumm...@btconnect.com>
wrote:
> On Sat, 26 Jul 2008 06:04:01 -0700 (PDT), rickman <gnu...@gmail.com>
> wrote:
>
> >On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com>
> >wrote:
> >> On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley
>
> >> It may be personal preference, but I find if-then-else MUCH easier to
> >> read in somebody else's code.
>
> >> ?: does save a few of those precious characters though.
>
> >> - Brian
>
> >The problem is not so much reading the code, but is writing.  I think
> >in the terms of the logic, usually a schematic/block diagram.  Then I
> >try to express that logic in the language.
>
> This may be a cheap shot, but I think it's telling that, even in the
> presence of a clear text specification ...>Example: A data mux controlled by the output of an AND of a signal and
> >the output of a mux.
>
> and a correct VHDL description...
>
> >  BERTEn <=      '0' when BERTSel = '0' else
> >            not SyncPOSSel when GenEn = '0' else
> >            not GenPOSSel;
> >Compare the two examples to this code...
> >  BERTEn <=      BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>
> ... the one-line Verilog implementation is either wrong, or confusing to
> several industry experts! (I don't know which; I'm definitely not cut
> out for Verilog)

But it is *not* a Verilog implementation.  It is VHDL with a new
construct thrown in.  The error (btw, who made the error???) is
because this is not a defined function and since I didn't use
parenthesis, it was open to interpretation with no guidelines.  If you
really think that the cause of the misinterpretation by one of us
shows it is a poor construct, then you deserve the verbosity of
VHDL.

A language does not need to protect you from yourself if you are any
good.  I realized a long time ago that computer tools were initially
designed for computer designers.  But there aren't enough good
designers to go around.  So the tools were dumbed down so that the
masses could use them.  I don't agree that this is even needed.  What
is needed is a bit of education in how to write code that is not hard
to debug and then getting people to use those principles as well as
the principles of good test techniques.

The bottom line is that I don't need to turn a one line statement into
a 9 line program in order to make its meaning clear.


> I don't believe this was a deliberate plot on Jonathan's or Mike's part
> to diss Verilog, but YMMV.
>
> >This is what I expect a concurrent statement to look like, not to
> >mention that it represents exactly the image I had in my head and on
> >the whiteboard, making it much easier to write.
>
> If you mean the brevity rather than the form, I actually agree, though
> as written I couldn't tell you what it does. (Rewritten with
> parentheses, I could figure it out eventually)

Eventually???  It has two operators.  One maps exactly to a mux and
the other maps exactly to an AND gate.  Why would that take more than
a second to understand???
                ___
   |\        ---|  \
---| \          |  |------
   | |----------|__/
---| /
   |/

Why would it be hard to translate the code into this diagram?
(assuming that you can view the diagram in a non-proportional font)?

> But I don't see what's wrong with
>
> BERTEn <= BERTSel and ( not SyncPOSSel when GenEn = '1'
>                                        else not GenPOSSel);
> which I believe does the same thing.

Are you sure that this is valid syntax?  I was under the impression
that a conditional signal assignment was just that, an assignment, not
an expression to be mixed in with other expressions.  I can't get the
Active-HDL compiler to accept it.  Did I mess it up or does this not
work?

I guess that is the difference between the VHDL construct and the
selection operator.  The selection operator is an expression and the
VHDL construct is an assignment not to be mixed with other
expressions.

Rick

On Jul 28, 9:41 am, rickman <gnu...@gmail.com> wrote:
> A language does not need to protect you from yourself if you are any
> good.  I realized a long time ago that computer tools were initially
> designed for computer designers.  But there aren't enough good
> designers to go around.  So the tools were dumbed down so that the
> masses could use them.  I don't agree that this is even needed.  What
> is needed is a bit of education in how to write code that is not hard
> to debug and then getting people to use those principles as well as
> the principles of good test techniques.
>
> Rick

If you're so in love with Verilog's capabilities, use verilog.

The rest of us, who are apparently not any good since we prefer a
strong language like VHDL, will continue to use VHDL.

BTW, just in case you want to risk taking our inferior advice, if you
are dead set on a more concise notation in currently legal vhdl, then
create an array type indexed by boolean (or std_logic). Then create a
signal/variable and assign the two elements appropriately. Now you can
implement your concise expression by indexing the array with your
selection expression.

Andy

rickman wrote:
> On Jul 26, 9:38 am, Mike Treseler <mtrese...@gmail.com> wrote:
>> rickman wrote:
>>>   BERTEn <=     BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
>>      if BERTSel and GenEn then
>>         BERTEn <= not SyncPOSSel;
>>      else
>>         BERTEn <= not GenPOSSel;
>>      end if;
> 
> One of us doesn't understand the precedence (I'm not sure which
> one...).  That is always a good reason for not allowing precedence
> defaults to define an expression...
> 
>    BERTEn <=     BERTSel and (GenEn ? not SyncPOSSel : not GenPOSSel);
> 
> Is that more clear?
> 
> Rick

As a potential three-line solution:

signal BERTEn_mux_n : std_logic;
...
BERTEn_mux_n <= SyncPOSSel when (GenEn = '1') else GenPOSSel;
BERTEn       <= BERTSel and (not BERTEn_mux_n);

And trust in your synthesis tools to fold the intermediate signal.  It 
certainly eliminates any ambiguity about what's going on where in what 
order.

-- 
Rob Gaddi, Highland Technology
Email address is currently out of order

rickman <gnuarm@gmail.com> wrote:

>On Jul 26, 7:56 am, Brian Drummond <brian_drumm...@btconnect.com>
>wrote:
>> On Sat, 26 Jul 2008 10:31:32 +0100, Jonathan Bromley
>>
>>
>>
>> <jonathan.brom...@MYCOMPANY.com> wrote:
>> >On Fri, 25 Jul 2008 22:46:26 -0700 (PDT), rickman wrote:
>>
>> >>In VHDL an operator can be overloaded.  But can a new operator be
>> >>created?  There is more than once I would like to use the very concise
>> >>notation available in Verilog such as the select operator.  Is there a
>> >>way to create the selection operator in VHDL?  Looking at the
>> >>structure, I guess it just doesn't fit the mold for VHDL with three
>> >>operands.
>>
>> More dynamic OO languages support arbitrary operator creation; Smalltalk
>> would be an example, or the old Linn Lingo.
>>
>> It's not VERY complicated _in_that_environment_ where static typing is
>> almost non-existent (strong typing can be rigorous, but implemented at
>> runtime) BUT ...
>> (1) you are limited to the creation of binary operators; so ?: is still
>> tricky, to put it mildly, and
>> (2) operator precedence is usually predetermined and deeply embedded in
>> the parser. The above languages solved this problem by allocating
>> precisely one precedence level to all operators - in other words, use
>> brackets.
>>
>> I suspect extensible operator precedence was the main complexity in
>> ALGOL-68.
>>
>> But anyway I suspect you'd have to destroy VHDL to add extensible
>> operators...
>>
>> >>I know I can create a function for this such as select(sel,a,b), but I
>> >>like the form of the notation sel ? a : b, very clear and concise.  I
>> >>guess I could always switch to Verilog... :^)
>>
>> It may be personal preference, but I find if-then-else MUCH easier to
>> read in somebody else's code.
>>
>> ?: does save a few of those precious characters though.
>>
>> - Brian
>
>The problem is not so much reading the code, but is writing.  I think
>in the terms of the logic, usually a schematic/block diagram.  Then I
>try to express that logic in the language.  It is not uncommon that it
>is simply impossible to express the logic in the form I have drawn
>it.  Then I have to convolute it to come up with something that is
>what I have drawn, or at least I hope so.

I don't think drawing logic is a good way to start. Using flow charts
usually leads to more simple solutions because it is easier for a
human to optimize a flow chart than a bunch of logic symbols.

>Example: A data mux controlled by the output of an AND of a signal and
>the output of a mux.  This is four control signals gated together to
>drive the control on the data mux.  Here is what I ended up with.
>
>  BERTEn <=	'0' when BERTSel = '0' else
>		not SyncPOSSel when GenEn = '0' else
>		not GenPOSSel;
>
>I don't think that the diagram I drew comes to mind when you see this
>code.  Maybe a process with an IF statement would be slightly more
>clear, but the verbosity presents an obfuscation of its own from the
>"clutter" created.
>
>process (  BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
>  if (BERTSel = '0') then
>    BERTEn <=	'0';
>  elsif (GenEn = '0') then
>    BERTEn <=	not SyncPOSSel
>  else
>    BERTEn <=	not GenPOSSel;
>  end if;
>end process;
>
>The clutter is from the sheer size of the code.  The first three line
>example is a bit obtuse, the 9 line example is large enough to make it
>hard to see the rest of the code and so to see how it fits into the
>big picture.  Compare the two examples to this code...
>
>  BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;

This construction wouldn't be very clear for people that are
relatively new to a programming language. I'd try to avoid it.

How about:

process (  BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
 if (BETRSel and Genen)='0' then
    BERTEn <=	not SyncPOSSel
  else
    BERTEn <=	not GenPOSSel;
  end if;
end process;

The code above makes perfectly clear what you are doing. Besides, I
doubt your examples are describing the same logic.

>This is what I expect a concurrent statement to look like, not to
>mention that it represents exactly the image I had in my head and on
>the whiteboard, making it much easier to write.
>
>I am sure there are those who disagree and much prefer the verbose
>process.  Maybe I'm just not cut out for the regimen of VHDL.

I see your point and I agree. I would like to write my programmable
logic in C as well. Neither VHDL or Verilog are easy to use. 

Yet, you could run your VHDL code through a C pre-processor. This
would allow macro substitution.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

Nico Coesel wrote:

>>  BERTEn <=	BERTSel and GenEn ? not SyncPOSSel : not GenPOSSel;
> 
> This construction wouldn't be very clear for people that are
> relatively new to a programming language. I'd try to avoid it.
> 
> How about:
> 
> process (  BERTSel, SyncPOSSel, GenEn, GenPOSSel) begin
>  if (BETRSel and Genen)='0' then
>     BERTEn <=	not SyncPOSSel
>   else
>     BERTEn <=	not GenPOSSel;
>   end if;
> end process;

Thread recursion has begun,
and there may be no exit condition ;)

         -- Mike Treseler

On Mon, 28 Jul 2008 07:41:25 -0700 (PDT), rickman <gnuarm@gmail.com>
wrote:

>The bottom line is that I don't need to turn a one line statement into
>a 9 line program in order to make its meaning clear.

Absolutely.

>> (Rewritten with parentheses, I could figure it out eventually)
>
>Eventually???  It has two operators.  One maps exactly to a mux and
>the other maps exactly to an AND gate.  Why would that take more than
>a second to understand???

For the 2-input mux shown, eventually means a second or two (and book
time to determine the precedence versus "and"). But which way round is
the mux, for example, if negative logic is involved? Or a more complex
expression with a lot more than four signals; try extending the example
to a 13 input mux.

>> But I don't see what's wrong with
>>
>> BERTEn <= BERTSel and ( not SyncPOSSel when GenEn = '1'
>>                                        else not GenPOSSel);
>> which I believe does the same thing.
>
>Are you sure that this is valid syntax?  I was under the impression
>that a conditional signal assignment was just that, an assignment, not
>an expression to be mixed in with other expressions.  

Unfortunately you are right; that is precisely what is wrong with it.
Not enough coffee this morning, obviously. I apologise for not having
run it through a simulator first; I don't have one on this machine.

I suspect Rob's three-line solution (2 lines + declaration) is as close
as VHDL can come. Or, since and is transitive, just push it through into
the expressions, as I think was suggested;

BERTEn <= ( BERTSel and not SyncPOSSel) when GenEn = '1'
            else ( BERTSel and not GenPOSSel);

Which is moderately clear; and likely to be so in six months or four or
ten years when you (or your successor) re-visits the design.

If you are doing this a lot, then do it only once; wrap it in a
function.

>I guess that is the difference between the VHDL construct and the
>selection operator.  The selection operator is an expression and the
>VHDL construct is an assignment not to be mixed with other
>expressions.

Yes; the selection would have been an expression; unfortunately it would
have been a nasty wart in the syntax and probably broken the parsing
model. For very limited benefit; 2 is a special case of n.

The conditional assignment is a second best for usability, but fits the
big picture better. Assignment can take other characteristics; "after
4ns" or "guarded", so one more doesn't upset the cart, and it is not
limited to 2 inputs.

I think where we differ is that I side with keeping the big picture
simple and consistent; I believe it pays in the long run, despite the
short term cost, such as an occasional extra line (not 9 please!).
Unfortunately that makes VHDL a hard sell, because it doesn't come
across clearly in a little 1-month or 3-month project.

I repeat I don't know Verilog, but if it has ?: selection operator it
probably inherited that from C, where so many useful-looking oddities
break the principle of simplicity, and in such basic ways, I am forever
amazed (and still, occasionally, surprised. Is it the only language that
lets you declare constants but won't let you use them in a constant
expression when you declare an array? Or that will let you perform
single precision FP arithmetic, then makes the the same code deliver
different results when you abstract it into a function, because it
silently changed to double precision?)

I presume (at least sincerely hope) Verilog is better, but the little
time I spent studying it gave me the same uneasy feeling. 

Fortunately I get to choose my hardware language; I'm working on
replacing C and C++ for the software side, but it's going to take a
while.

- Brian

On Mon, 28 Jul 2008, Rickman wrote:
|-------------------------------------------------------------------------|
|"[..]                                                                    |
|                                                                         |
|A language does not need to protect you from yourself if you are any     |
|good.  I realized a long time ago that computer tools were initially     |
|designed for computer designers.  But there aren't enough good           |
|designers to go around.  So the tools were dumbed down so that the       |
|masses could use them.  I don't agree that this is even needed."         |
|-------------------------------------------------------------------------|

I once read a claim in a book (unfortunately I can not rememember
which one and it shall be many months before I shall be able to
check), that Albert Einstein was once returning home via the visitors'
entrance of the complex in which he resided at in those days, and he
asked for Mr. or Dr. Einstein, and a few seconds later he admitted to
being embarrassed because after asking for Einstein, he remembered
that he was Einstein. People do not perform at their best at every
moment they are working. If I cycle a bike near broken glass on the
road, then I tend to cycle more cautiously than when the road is
clear. I almost never cycle without a helmet though I have never been
in a situation in which I would have been seriously injured or died if
I had not been wearing a helmet.

People who are not mountain climbers had been surprised to hear that I
have climbed without a rope. I do not usually climb high enough to die
from a fall on my own without a rope, but I have done it (without a
helmet). When doing so, I have paid a lot of attention to not making a
fatal mistake. (Much better climbers than I had died, so being
excellent at something does not guarantee that something unfortunate
shall never happen.) Even so, I tend to ordinarily deliberately go
towards a handrail when I am about to walk on a very wide staircase.

Electric sockets and plugs in every country in which I have resided
have been designed in such a way that they can not be easily connected
in a dangerous fashion.

|-------------------------------------------------------------------------|
|"  What                                                                  |
|is needed is a bit of education in how to write code that is not hard    |
|to debug and then getting people to use those principles as well as      |
|the principles of good test techniques.                                  |
|                                                                         |
|[..]"                                                                    |
|-------------------------------------------------------------------------|

A little education does not go a long way.

C. P. G.