Subject: ISSUE #?? Proposal: "queueable" attribute for functions
From: Stickley, John (john_stickley@mentorg.com)
Date: Tue Nov 26 2002 - 08:20:11 PST
Team,
I just wanted to squeeze in one last requirement issue before today's
deadline
for issues.
I would like to request a simple attribute that we can add to
extern/export
declarations called queueable.
What this does is to gives the compiler a hint that a function call can
be
queued rather than having to wait for a full round trip confirmation
that the
callee has been called and has returned.
It turns out that this simple extension to our function call interface
elegantly
opens up a whole facility to implement the equivalent of SystemC
channels,
Berkeley sockets, message queues, Unix named pipes, etc.
Ironically, the OpenVera LRM has a similar facility called the VSV
interface.
So they apparently recognized the need to have something above and
beyond DirectC for this type of capability.
But what this proposal does is it gives you the entire capability
without
adding a whole new API to support it.
With an ultra simple modification of DirectC, you can cleanly support
a socket type of channel like VSV did.
This is extremely useful for creating efficient 1-way blocking and non
blocking
channels between SV processes and C threads. Queueable functions are
ideal for implementing efficient, optmized streaming channels between
models.
And, in an implementation, if you've paid the price to imiplement
DirectC
function calls, with slightly more work you can get this feature almost
for free.
The only requirement of queueable functions they can only have input
arguments, no outputs. Think of these as one way transaction channels
that the infrastructure can queue to arbitrary depth before blocking the
caller.
Here's an enhanced syntax that shows the queueable attribute:
extern_decl ::=
extern [attribute {, attribute}]
return_type fname ( [arg {,arg} );
attribute ::= pure | queueable
export_decl ::=
export [attribute {, attribute}]
[scopename{::scopename}::]fname ["cname"];
scopename ::= modulename|interfacename
attribute ::= pure | queueable
By placing the queueable attribute on the function declarations the user
is
hinting to the compiler that it can do this one-way optimization. In
many cases
that will save having to send extra messages in the opposite direction
when the
function call returns. Remember, even if the function has a void return
argument,
a return confirmation message is still required on a non-queueable
function call.
I've attached a revision of my PowerPoint proposal that adds this.
-- johnS
__
______ | \
______________________/ \__ / \
\ H Dome ___/ |
John Stickley E | a __ ___/ / \____
Principal Engineer l | l | \ /
Verification Solutions Group | f | \/ ____
Mentor Graphics Corp. - MED C \ -- / /
17 E. Cedar Place a \ __/ / /
Ramsey, NJ 07446 p | / ___/
| / /
mailto:John_Stickley@mentor.com <mailto:John_Stickley@mentor.com> \
/
Phone: (201)818-2585 \ /
---------
This archive was generated by hypermail 2b28 : Tue Nov 26 2002 - 08:24:43 PST