New operator creation

G

Grigorios Angelis

Does anyone know if it is possible and how to define new operators in vhdl.

A very usefull one for example would be a "++" operator which would behave
as its c counterpart.

Possible use:
signal MySignal : integer := 0;
 
E

Egbert Molenkamp

Grigorios Angelis said:
Does anyone know if it is possible and how to define new operators in vhdl.

A very usefull one for example would be a "++" operator which would behave
as its c counterpart.

Possible use:
signal MySignal : integer := 0;
.
.
.
process (clock) is
begin
if rising_edge(clock) then
MySignal ++
end if;
end process;

The first (of some) error message that I seem to get from the compiler when
I try to declare a function "++" is the following:

Not a predefined operator: "++"

Which is kind of a given because the reason I'm trying to make the operator
is exactly because it's not predefined.

Only predefined operators can be overloaded.

Egbert Molenkamp
 
J

Jonathan Bromley

Egbert Molenkamp said:
Only predefined operators can be overloaded.

It's very interesting to ask why this should be so.

Infix operators may have (or lack) many properties that
the compiler needs to know about:
associativity (left, right, none?)
commutativity (needed when optimising a syntax tree)
distributivity (also important for some optimisations)
binding precedence

When you permit unary operators to be either prefix or
postfix, like ++ in C, then things get even more complicated.

Consequently it's very difficult to design a language in which
you can freely define your own operators. When you overload
the VHDL built-in operators, all their other properties, as
mentioned above, remain unchanged - they are built in to the
compiler.

Algol-68 allowed arbitrary operator definition - it was one
of the most complicated features of the language. Does
anyone know of any other languages that offer it?

Be happy with regular procedures. After all, when you want
s++
it's not outrageously hard to write instead
incr(s)
using your own procedure incr().
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: (e-mail address removed)
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
B

Brian Drummond

It's very interesting to ask why this should be so.

Infix operators may have (or lack) many properties that
the compiler needs to know about:
associativity (left, right, none?)
commutativity (needed when optimising a syntax tree)
distributivity (also important for some optimisations)
binding precedence

When you permit unary operators to be either prefix or
postfix, like ++ in C, then things get even more complicated.

Consequently it's very difficult to design a language in which
you can freely define your own operators. When you overload
the VHDL built-in operators, all their other properties, as
mentioned above, remain unchanged - they are built in to the
compiler.

Algol-68 allowed arbitrary operator definition - it was one
of the most complicated features of the language. Does
anyone know of any other languages that offer it?

There seem to be two solutions to this problem; increase the language's
complexity, or reduce it. In the first; when you define a new operator,
you need some mechanism to register it's precedence (say, as equal to
'+', or between '+' and '*') - or allow more general manipulation of
precedences. This is presumably the Algol-68 approach.

Or you can simplify the language.

Linn's Lingo was the language of the Rekursiv object-oriented CPU - it
had much of the dynamic nature of Smalltalk, but with a more 'C' like
syntax. One feature was that you could redefine or add operators as you
wished.

All operators had the same precedence, thereby avoiding the problem!
Association was made explicit by the programmer, with parentheses.

If it's not outrageously hard to write "incr(s)" instead of "s++", then
neither is it too hard to write "a + (b*c) + d" to prevent surprises.
Indeed, I tend to follow that style anyway, I feel it adds clarity for
the (human) reader.

NOTE - I am NOT recommending that VHDL adopt this style! just commenting
that it IS a viable alternative to operator precedence, allowing for
arbitrary operator definition in a very simple and clean manner.

- Brian
 
J

Jonathan Bromley

There seem to be two solutions to this problem; increase the language's
complexity, or reduce it. In the first; when you define a new operator,
you need some mechanism to register it's precedence (say, as equal to
'+', or between '+' and '*') - or allow more general manipulation of
precedences. This is presumably the Algol-68 approach.

Yup. It's not just precedence, of course. VHDL permits
a and b and c
but forbids
a nand b nand c
for perfectly good reasons - but how could you register this
behaviour when creating a new operator?
[In] Linn's Lingo [...]
All operators had the same precedence, thereby avoiding the problem!
Association was made explicit by the programmer, with parentheses.

occam took the same approach. It also made operators non-associative,
so that
a + b + c
was illegal - you had to write
(a + b) + c
instead. C programmers hated it, of course - especially the
kind that take delight in stuff like
for(i=0,j=k;j--;)*a++=b+=*c++;
If it's not outrageously hard to write "incr(s)" instead of "s++", then
neither is it too hard to write "a + (b*c) + d" to prevent surprises.
Indeed, I tend to follow that style anyway, I feel it adds clarity for
the (human) reader.

I tend to agree. I've learnt far too many programming languages
in my time, and I nowadays determinedly refuse to remember trivia
like operator precedence :)

--

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: (e-mail address removed)
Fax: +44 (0)1425 471573 Web: http://www.doulos.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
 
B

Brian Drummond

Algol-68 allowed arbitrary operator definition - it was one
of the most complicated features of the language. Does
anyone know of any other languages that offer it?

There seem to be two solutions to this problem; increase the language's
complexity, or reduce it.
[In] Linn's Lingo [...]
All operators had the same precedence, thereby avoiding the problem!
Association was made explicit by the programmer, with parentheses.

occam took the same approach. It also made operators non-associative,
so that
a + b + c
was illegal - you had to write
(a + b) + c
instead.

Lingo didn't go that far; associativity was strictly left to right, so
that (for example) "a nand b nand c" would at least have a defined
result.
I tend to agree. I've learnt far too many programming languages
in my time, and I nowadays determinedly refuse to remember trivia
like operator precedence :)

Yes. And it's interesting how much easier languages with well defined
syntax and semantics are to come back to, after spending time on
something else.

- Brian
 
E

Eric Smith

Egbert Molenkamp said:
Only predefined operators can be overloaded.

Jonathan Bromley said:
It's very interesting to ask why this should be so.

Because you can't write a grammar (or parser) for the language if th
operators are unknown. C++ and Ada don't allow you to make up new
operators either.

Operator syntax is only syntactic sugar for a functional call anyhow.
As Alan Perlis observed, syntactic sugar causes cancer of the semicolon.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top