New operator creation

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;

Grigorios Angelis

"Grigorios Angelis" <> schreef in bericht
news:c1006g$kl0$...
> 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

Egbert Molenkamp

"Egbert Molenkamp" <> wrote
in message news:c10jam$2p4$...
>
> 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:
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.

Jonathan Bromley

On Thu, 19 Feb 2004 12:20:55 -0000, "Jonathan Bromley"
<> wrote:

>"Egbert Molenkamp" <> wrote
>in message news:c10jam$2p4$...
>>
>> 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?

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

Brian Drummond

"Brian Drummond" <> wrote in
message news:...

> >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.

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:
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.

Jonathan Bromley

On Thu, 19 Feb 2004 16:54:24 -0000, "Jonathan Bromley"
<> wrote:

>"Brian Drummond" <> wrote in
>message news:...
>
>> >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.

>> 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

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

Brian Drummond

"Egbert Molenkamp" <> wrote
> Only predefined operators can be overloaded.

"Jonathan Bromley" <> writes:
> 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.

Eric Smith