RE: [sv-bc] Function return values

Jonathan,

I have just a couple of comments, not a major disagreement.

I believe that allowing a return with no expression from a function adds
no value to the language. If users want/need to rely on the return value
of the function they can easily do that by writing "return(
function_name )". That makes their intent explicit. Also, as you point
out, allowing return with no expression would prevent the protection
from certain kinds of folly.

Also, using the value associated with the function name will work
regardless of the function's lifetime (static or automatic), albeit with
different semantics. A call to an automatic function that does not
overwrite the return value will not return the value returned by the
last call to the function; instead, it returns the un-initialized value
that corresponds to the return datatype.

Finally, it would be valuable to change *all* functions to automatic,
not just the ones in programs, but also the ones in synthesizable code.
Relying on the static nature of the function introduces inefficiencies
in the implementation tools, particularly, routers need to connect all
function call sites to the same memory. Automatic functions provide much
cleaner semantics for hardware by dissociating the affect of one call
site from the others.

	Arturo

-----Original Message-----
From: owner-sv-bc@eda.org [mailto:owner-sv-bc@eda.org] On Behalf Of
Jonathan Bromley
Sent: Thursday, March 01, 2007 7:52 AM
To: Rich, Dave; sv-bc@eda-stds.org
Subject: RE: [sv-bc] Function return values

Dave,

> I hope that I never see anyone depend on the static value of 
> a function name, or the static value of output arguments
> to tasks and functions. 

The implied chastisement is understood and accepted :-)

I couldn't agree more with you, but there's no doubt that the
static nature of Verilog tasks and functions *could* be put
to good use, with enough care.  So people did it, and for my
own part as a trainer I have always tried to be as clear-
headed as possible about it with students; there's no point
in skating over something that's out there and represents
a serious trap for the unwary.

In practice, I have always avoided relying on the static
value of a function name, or of task arguments; it's just
too opaque for my taste.  Static local variables in a
subprogram, though, are valuable in traditional Verilog.

> It too bad we can't switch the default lifetime to automatic. 

It *is*, for classes; and we can easily declare programs
to be automatic.  So it's feasible and appropriate to 
move forward cleanly, once you've embraced the brave new
software-like world.

"Everything is static" was a key unifying principle of 
Verilog; much of what I found difficult about the language
suddenly became clear once I'd grasped that.  One of the
real strengths of SV is that it's contrived to build its
dynamic universe on top of that Verilog heritage whilst
retaining full backward compatibility.
-- 
Jonathan Bromley, Consultant

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

Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24
1AW, UK
Tel: +44 (0)1425 471223                   Email:
jonathan.bromley@doulos.com
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.

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.



-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.