Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » DSDP - Real-Time Software Components (RTSC) » Instance Proxies(A proposal for instance proxies)
Instance Proxies [message #1727866] Mon, 28 March 2016 17:27 Go to next message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
Thanks to a tip from James Lockwood, I was able to create generic peripheral drivers that could reference multiple modules with the same target code implementation. To do this I created an interface module for the driver in question and one or more concrete implementations that inherit from the interface. In the target code a call is made to the interface functions with instance handles declared in the Instance_State struct. An example implementation for UART is contained in this thread. This works due to a vtable like implementation:

IUART.h
static inline xdc_Int drivers_IUART_read( drivers_IUART_Handle __inst, xdc_Void *buffer, xdc_SizeT size )
{
    return __inst->__fxns->read((void*)__inst, buffer, size);
}

While this is perfectly acceptable it does rely on function pointers. The compiler will not be able to optimize this call so you incur additional overhead. This is in contrast to a proxy/delegate implementation where calls are made to module function directly:
xdc_Int drivers_UART_UARTProxy_read__E( drivers_UART_UARTProxy_Handle __inst, xdc_Void *buffer, xdc_SizeT size )
{
    return csl_host_UART_read((csl_host_UART_Handle)__inst, buffer, size);
}

The optimizer can remove this intermediate call saving the runtime overhead. It is for this reason that I would like to add support for instance proxies. We already have all the information necessary to make this happen. My intermediate proxy module generates an object table for each instance I create:
drivers_UART_Object__ drivers_UART_Object__table__V[1] = {
    {/* instance#0 */
        &drivers_UART_Module__FXNS__C,
        (drivers_UART_UARTProxy_Handle)&csl_host_UART_Object__table__V[0],  /* pinst */
    },
};

Armed with this information we could feasibly generate the proxy call like this:
xdc_Int drivers_UART_UARTProxy_read__E( drivers_UART_UARTProxy_Handle __inst, xdc_Void *buffer, xdc_SizeT size )
{
    if (__inst == (drivers_UART_UARTProxy_Handle) &csl_host_UART_Object__table__V[0])
    {
        return csl_host_UART_read((csl_host_UART_Handle)__inst, buffer, size);
    }
    else if (__inst == (drivers_UART_UARTProxy_Handle) &<some_other>_UART_Object__table__V[<inst_num>])
    {
        return some_other_UART_read((some_other_UART_Handle)__inst, buffer, size);
    }
    // More IUart else ifs...
    else
    {
        /* Handle runtime created/constructed instances */
        return __inst->__fxns->read((void*)__inst, buffer, size);
    }
}

Although this looks ugly the optimizer can remove this intermediate call in all cases except runtime created/constructed instances. In the later cases the overhead is expected. Most of the other generated functions in the PROXY BODY section can be extended in a straightforward manner except Object__create__S and Params__init__S. It may be possible to use/add information in the params structure to test what instance is being created/initialized. My first guess would be if a field in the params was set to &<Pkg>_<Mod>_Object__PARAMS__C then a test could be performed. This would not work if the client explicitly initialized their params without calling the appropriate Params_init function. However it's unlikely that __self was set by the user in this case and the call to Core_createObject would assert. Perhaps __self could be assigned to od->prmsInit instead which should be the same as &<Pkg>_<Mod>_Object__PARAMS__C? The only problem I see there is the call to Core_assignParams would wipe out __self, but this could be fixed easily.

Looking at the documentation there may be significant overlap between my proposal and instance factories. The biggest difference is my proposal is one proxy to many delegates whereas factories is one proxy to one delegate with many choices for that delegate. Not having the implementation of factories available makes it hard to judge how much ground work is in place, but I don't see why both concepts couldn't coexist. I would love to get everyone's input on this proposal and some pointers on how I would go about prototyping the implementation.

Thanks,

Chris
Re: Instance Proxies [message #1728094 is a reply to message #1727866] Thu, 31 March 2016 01:04 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 114
Registered: July 2009
Senior Member
Chris,
I am looking into your proposal, but it will take me some time to respond because of the limited time I can devote to it right now. But, I definitely want to thank you for making an effort to improve RTSC.
Re: Instance Proxies [message #1740460 is a reply to message #1728094] Sat, 13 August 2016 14:41 Go to previous messageGo to next message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
Sasha,

I'd like to try prototyping code to for instance proxies. Looking over the source I see that spec processing occurs in a handful of Java files which are fed by a parser/lexer built from an Antlr grammar file. I assume a good place to start would be to modify the grammar by adding proxyDecl to instDecl.

Being new to Java and having never used Antlr mean I'm stuck trying to rebuild RTSC. I see a makfile that should take care of rebuilding the parser, lexer, and java code, but it appears that there is an implied (Linux?) environment required for the build in xdc_java.mak along with other variables not defined in the make files. Would you be able to outline the build procedure and the required environment?

Thank you,

Chris
Re: Instance Proxies [message #1742149 is a reply to message #1740460] Wed, 31 August 2016 18:39 Go to previous messageGo to next message
Sasha Slijepcevic is currently offline Sasha SlijepcevicFriend
Messages: 114
Registered: July 2009
Senior Member
Chris,
sorry for not responding earlier, it seems I am getting email notifications only for new threads not for new posts.
Since you are only rebuilding the core Java packages, the quickest way to do it is to start from an installation and then just drop the sources from git into the core Java packages that you want to rebuild.
Then, you need to define the environment variable JDK to point to your JDK installation, to the directory that contains 'bin', 'include', 'lib', etc.
Finally, you'll have to reference some jar files in custom.mak in the package you are trying to build. You'll probably have to do a little bit of trial and error to find out which packages are missing, but I think if you just add whatever I added to JCPATH in custom.mak for xdc.services.intern.gen, you should be fine:
JCPATH := $(PKGROOT)$(PATHCHAR)$(RHINO)$(PATHCHAR)$(ANTLR)$(PATHCHAR)$(ECLIPSE)$(PATHCHAR)$(XDCROOT)/packages/xdc/services/global/java/package.jar$(PATHCHAR)$(XDCROOT)/packages/xdc/services/spec/java/package.jar$(PATHCHAR)$(XDCROOT)/packages/xdc/services/intern/xsr/java/package.jar$(PATHCHAR)$(XDCROOT)/packages/xdc/services/intern/cmd/java/package.jar
Let me know how it goes, and I'll try to fix my notifications so I'll respond sooner.
Re: Instance Proxies [message #1742531 is a reply to message #1742149] Sat, 03 September 2016 00:15 Go to previous message
Chris H is currently offline Chris HFriend
Messages: 11
Registered: September 2014
Junior Member
Sasha,

I was able to get the package to build after a little trial and error. Here are the steps I performed to build a new jar:

1) Check out org.eclipse.rtsc.xdccore to the same version as the local XDC Tools install (B21 in my case)
2) Copy all .java, package.bld, custom.mak, and, in my case, Grammar.g files from Git to the working install of XDC Tools.
3) Modify custom.mak by appending locations of the package dependencies you mentioned and replace $(XDCROOT)/packages/xdc/services/spec/java/package.jar with $(XDCROOT)/packages/xdc/services/intern/gen/java/package.jar
4) Modify xdc_java.mak to override XDCTOOLS_JVM1.6_BOOTCLASSES with $(JDK)/jre/lib/rt.jar
5) Run xdc .libraries (don't call xdc clean!)

I can now add proxies to the instance sections and generate the header files without errors. I'm sure I have more questions as I start the real development, but for now this gets me going.

Thank you!

Chris
Previous Topic:news.eclipse.org is shutting down.
Next Topic:Generated code for object member of variable length structs
Goto Forum:
  


Current Time: Fri Jun 22 17:35:47 GMT 2018

Powered by FUDForum. Page generated in 0.01562 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top