External Code Integrations Within a Computing Environment
Processing external code includes: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on user selection or specifying the first attribute in response to available information provided to a user interface system.
A portion of the disclosure of this patent document contains material that is subject to copyright protection. The copyright owner has no objection to facsimile reproduction by anyone of the patent document for the patent disclosure, as it appears in the United States Patent and Trademark Office patent file or records, but otherwise reserves all copyright rights whatsoever. Copyright© 2018 The MathWorks, Inc.
In one aspect, in general, a computing system for processing external code that is not native to a computing environment includes: a user interface system, configured to provide information to a user, and configured to receive response information from a user in response to the provided information; and a processing system, including at least one processor, configured to process the external code, the processing including: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, providing the available information to the user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
Aspects can include one or more of the following features.
The processing further comprises generating a user interface element for the second semantic entity and storing the user interface element in a library of the computing environment.
The processing further comprises generating a user interface element for the second semantic entity and using the user interface element in program code developed in the computing environment.
The user interface element comprises a graphical element in a graphical programming canvas environment, or a textual symbol callable from the computing environment.
The first attribute of the second set of one or more attributes comprises: a fixed point datatype, a sample rate, an input/output scope, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior.
The processing further comprises debugging the first entity using the second semantic entity in the computing environment.
The processing further comprises generating code for the first entity using the second semantic entity.
The processing further comprises performing cross-domain optimization across the first and second semantic entities.
The cross-domain optimization comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
The second semantic entity comprises: a named function associated with at least one input parameter or output parameter, a named variable associated with storage of a corresponding type, a named semantic category associated with a class or service, or a keyword associated with a type of a variable or parameter or associated with functionality for a semantic entity.
The second semantic entity comprises: a rate, a constant, a reference, a type, a structure, a state, or a service port.
The processing further comprises integrating documentation associated with the first semantic entity into documentation associated with the second semantic entity.
In another aspect, in general, a method for processing external code that is not native to a computing environment includes: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
In another aspect, in general, one or more non-transitory computer-readable media have stored thereon instructions for processing external code that is not native to a computing environment, where the instructions, when executed by a computing system, cause a computing system to perform operations comprising: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
In another aspect, in general, a method includes: generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising: identifying a semantic entity of the fifth code, mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code, and generating the second code based on the mapping the semantic entities of the fifth code and the fourth code.
Aspects can include one or more of the following features.
Generating the second code comprises generating a function call to the fourth code.
Generating the second code comprises generating code for the third code and including the function call with the code generated for the third code.
Generating the second code comprises in-lining the fourth code in the generated second code.
The fourth code comprises at least one of: C, C++, C#, Java®, FORTRAN, Python, Visual Studio®.
1 OverviewExamples of such an environment can include a modeling and/or simulation environment, and a technical computing environment. Within the computing environment 100, program code 102 in one or more languages native to the computing environment 100 can be compiled and/or executed. An example of such program code 102 can be code that implements a program in the form of an executable model. Some program code in the computing environment 100 can be organized within packages/libraries 104, which may be used to execute, interpret, or otherwise run software developed using the computing environment 100. The program code 102 can include textual code, graphical code, or a combination thereof. The packages/libraries 104 may include, for example, sets of code, libraries, interfaces, and other data related to software developed using the computing environment 100.
The computing environment 100 may, for example, be the MATLAB® language/programming environment and the Simulink® model-based simulation and design environment, both MATLAB® and Simulink® being from The MathWorks, Inc. of Natick, Mass. Other examples platforms that can be used to provide the computing environment 100 include: OpenCV, AWS SDK for C++, OpenDDS, ZeroMQ, Qt, Halide, TensorFlow C++ API, Pytorch C++ API, Caffe, CImg, Libtiff, Crypto++, Tesseract, FreeImagePlus, LibXL, Tonic, Botan, and Tensorflow. Other environments can include, for example, the Simscape physical modeling system and the Stateflow® state chart tool also from The MathWorks, Inc., the MapleSim physical modeling and simulation tool from Waterloo Maple Inc. of Waterloo, Ontario, Canada, the LabVIEW virtual instrument programming system and the NI MatrixX model-based design product from National Instruments Corp. of Austin, Tex., the Keysight VEE graphical programming environment from Keysight Technologies, Inc. of Santa Clara, Calif., the System Studio model-based signal processing algorithm design and analysis tool and the SPW signal processing algorithm tool from Synopsys, Inc. of Mountain View, Calif., a Unified Modeling Language (UML) system, a Systems Modeling Language (SysML) system, and the System Generator system from Xilinx, Inc. of San Jose, Calif. Additional environments can be environments that support languages such as the C, C++, C#, and SystemC programming languages.
Programs developed with the computing environment 100 can use external code 106. In some cases, the external code 106 may have been developed within or otherwise using an (optional) external environment 108. The external environment 108 is, in this example, a development environment external to the computing environment 100. For example, the external environment 108 may refer to an integrated development environment that supports one or more coding languages (e.g., C, C++, C#, Java®, FORTRAN, Python, Visual Studio®, etc.). Examples of the external environment 108 can also include any of the example environments described as examples for the computing environment 100 above. External code can be in the form of one or more external libraries 110 or can contain instances of elements of the external libraries 110. The external code 106 may be written in a coding language that is native to (e.g., supported by, executable within, or compatible with) the external environment 108. In some implementations, the external code 106 is not necessarily provided from an integrated development environment such as the external environment 108, but may be provided from any source external to the computing environment 100.
The computing environment 100 includes an integration module 112, which is configured to integrate external code 106 into the computing environment 100. The integration module 112 is able to generate program code 102 that provides the functionality of the external code 106 in a manner that is more fully specified according to attributes that are native to the computing environment 100. In some cases, external code within the external library 110 may be processed by the integration module 112 and provided within packages/libraries 104. In some cases, the languages that are native to the computing environment 100 may be different from the languages that are native to the external environment 108. For example, the external code 106 may be written in a language that is not native to the computing environment 100. While the terms external and non-native may be used interchangeably, and the terms internal and native may be used interchangeably, for convenience a language or code that is not native to the computing environment 100 may be referred to herein as “external” and a language or code that is native to the computing environment 100 (such as program code 102) may be referred to herein as “internal.”
The integration module 112 can be implemented as software that integrates external code 106 or external libraries 110 from the external environment 108 into the computing environment 100. For example, the integration module 112 can map semantic entities (e.g., function calls, global variables, states, etc.) of the external code 106 to semantic entities of the program code 102. The integration of the external code 106 using the integration module 112 can allow development of program code 102 in the computing environment 100 to take advantage of existing external code 106 without requiring reprogramming within the computing environment 100 to perform the same functionalities of the external code 106. For example, existing numerical or simulation libraries in various programming languages external to the computing environment 100 can be integrated into the computing environment 100 for programming usage. Example platforms that may have libraries that can be integrated can include: OpenCV, AWS SDK for C++, OpenDDS, ZeroMQ, Qt, Halide, TensorFlow C++ API, Pytorch C++ API, Caffe, CImg, Libtiff, Crypto++, Tesseract, FreeImagePlus, LibXL, Tonic, or Botan, OpenCV, OpenDDS, and Tensorflow. Some of the libraries are highly optimized or known for performing certain functionalities, such as deep learning, computer vision, or encryption, within the respective external environments. Integration allows incorporation of some of the advantages of these libraries, which can be time/resource consuming to construct within the computing environment 100, or may not be suitable to be constructed due to the design of the computing environment 100. Additionally, the integration can also facilitate distributed program development, e.g., in a cloud-based environment or within an organization or other situations, possibly using different programming environments, and the program developed can be integrated at a system level. Examples of such use can include co-simulation in the computing environment 100 or system engineering in the computing environment 100. The integration module 112 can integrate the external code 106 and/or external library 110 directly into program code 102 being developed within the environment 100, or alternatively, into a packages/libraries 104 native to the computing environment 100 such that elements within the library can be used natively within the computing environment 100. Semantic entities of languages of the external code 106 can be mapped to semantic entities of languages internal to the computing environment 100, and wrappers can be formed around external libraries (e.g., the external libraries 110) and/or around the external code 106 to implement the semantic entity mapping.
The external code 106 may include a variety of different kinds of semantic entities. The semantic entities are code elements that are used to implement functionality within the code. Examples of semantic entities include rates (e.g., sample rate), constants, references, pointers, types and structures, states, global variables (e.g., as function input/output arguments), and the like. The structure and format of the semantic entities are indicated using attributes of those semantic entities. For example, an attribute of a semantic entity may refer to an argument, parameter, variable, or other element of the semantic entity which is used by the semantic entity during the execution thereof. The attributes of the semantic entities within the external code 106 may in some cases be common to languages internal to the computing environment 100. For example, the computing environment 100 and the external environment 108 may both support a coding language that uses, as a semantic entity, a function call (e.g., void foo(x, y, z)) having the attributes of an input argument, an output argument, and a parameter. In such a case, the integration module 112 does not need to perform mapping for the external code 106 to function within the computing environment 100. However, the semantic entities within the external code 106 may not map directly to corresponding entities in the computing environment 100. As such, the attributes within the semantic entities of the external code 106 may need additional annotation (such as fixed-point radix specification for an integer data) within the computing environment 100. The integration module 112 resolves situations such as these by determining how to map those semantic entities and under-specified attributes such as fixed-point data types to native semantic entities and their attributes of the computing environment 100.
The integration module 112 processes the external code 106 to identify semantic entities within the external code and their respective attributes, and corresponding semantic entities of the environment 100 that are capable of providing the same or equivalent semantic meaning to those of the external code 106. The integration module 112 parses the external code 106 to identify semantic entities within the external code 106 and then maps the external semantic entities and/or the attributes thereof from the external code 106 to internal semantic entities and/or attributes thereof native to the computing environment 100.
In some implementations, the integration module 112 parses the external code 106 to determine whether information regarding how to map a given semantic entity and the attributes thereof from the external code 106 to the computing environment 100 is specified within the external code 106. For example, the information can be obtained or derived where the external code 106 includes code that indicates how to use the semantic entity and the attributes thereof. For example, where the external code 106 includes a function (the external semantic entity) that has three arguments, the context for the function (e.g., the syntax used to call the function, the types and placement of arguments, and/or any embedded comments), may be analyzed to determine that one argument is an input, one argument is a parameter, and one argument is an output. By analyzing the external semantic entity and its context in this manner, an internal semantic entity and the attributes thereof may be specified. The integration module 112 computes a default specification of the internal semantic entity with the attributes of the internal semantic entity configured based on a rule set (e.g., const pointers are inputs etc.). Part or all of this default specification of the internal semantic entity can be overridden in the computing environment 100. For example, the overriding can be performed manually, or via decorations in the external representation. For example, comments in external code may include information about the semantic mapping to an internal code representation.
In some implementations, the integration module 112 performs parsing, mapping, and interface generation processes to integrate external source code in external code 106 by compiling the external source code into an executable (e.g., exe files, dynamic-link libraries (DLLs), etc.), or when provided an executable in external libraries 110, by wrapping the executable with an interface wrapper in order to access the wrapped executable in the computing environment 100. The parsing and mapping functionality of the integration module 112 parses the external code 106 to identify external semantic entities and attributes thereof within the external code 106 and then maps those identified external semantic entities to internal semantic entities supported by the environment 100.
However, in some cases, a given semantic entity and/or one or more attributes from the external code 106 may be under-specified, such that the use or purpose of the given semantic entity and/or one or more attributes thereof from the external code 106 for performing a particular functionality in the computing environment 100 is not readily clear to the computing environment 100. The occurrence of an under-specification indicates that the integration module 112 lacks some or all of the information necessary for mapping the given external semantic entity or attribute thereof to an internal semantic entity or attribute native to the computing environment 100. The integration module 112, upon detecting an under-specification (e.g., by pre-set default rules, or manually by the user, or by information that is provided in addition or as part of the external representation), identifies possible mappings for characterizing the underspecified semantic entity. The integration module 112 presents those possible mappings, such as for manual user review through a user interface system (e.g., using a user interface window that lists some or all of the possible mappings for selection, for example, by a user of the computing environment 100). The integration module 112 can use response information received through the user interface system to resolve the under-specification. Alternatively, or where no responsive information is received, the integration module 112 may refer to predetermined information available to the computing environment 100 to resolve the under-specification.
In some implementations, the integration module 112 can be used in connection with other operations supported by the computing environment 100 or external to the computing environment 100. For example, the operations may be one or more of code coverage reporting based on the program code 102, test vector generation, code testing, code debugging, or consistency checking of mappings of the external code 106 to entities of the computing environment 100. The operations can not only be performed on the native code of the computing environment 100, but also the external code 106 that is integrated through the integration module 112, without which the same operations cannot be readily available for the external code 106. For example, an external C++ library can be integrated and debugged using the debugging tools that are uniquely available in connection with the computing environment 100, but may not be readily available for C++ program code. In addition, other operations supported by the computing environment 100 such as requirements linking, report generation, coverage (statement, decision, MC/DC, toggle), optimization, static analysis, property proving, and automatic test vector generation can be performed on the integrated external code and are operations that are not always available in the external environment 108.
The integration module 112 is shown as software included within the computing environment 100. However, in some implementations, the integration module 112 may be located outside of the computing environment 100. For example, the integration module 112 may be part of a pre-processing environment that receives information from the external environment 108 and processes that information before transmitting that information to, or otherwise making that information available within, the computing environment 100. In some such implementations, the integration module 112 can be implemented as a plug-in or other software addition available for use in connection with the computing environment 100.
Examples of the external environment 108 or of other possible sources of the external code 106 that could be integrated include: OpenCV, AWS SDK for C++, OpenDDS, ZeroMQ, Qt, Halide, TensorFlow C++ API, Pytorch C++ API, Caffe, CImg, Libtiff, Crypto++, Tesseract, FreeImagePlus, LibXL, Tonic, or Botan. In some implementations, documentation (e.g., comments associated with external code to be integrated) can be integrated with the external code to improve the readability of the integrated external code. For example, the documentation may be or otherwise include documentation about the functionality of the external code or portions thereof, documentation relating to systems for using the external code, documentation regarding how semantic entities within the external code are to be used or otherwise integrated within the computing environment 100, or the like.
At 202, the external code is parsed, e.g., by the integration module 112 of
At 204, the semantic entities identified within the external code are mapped to internal entities associated with the computing environment 100. The internal semantic entities may include various attributes in a language of native code of the computing environment 100. For example, the input arguments, output arguments, and/or parameters of the external code 106 may be mapped to the semantically equivalent entities/language elements of the computing environment 100.
In some implementations, mapping an external semantic entity to an internal semantic entity includes identifying the attributes common to the external semantic entity and the internal semantic entity (e.g., name of a symbol, whether a function argument is input or output, type of a variable such as integer, double precision etc.). The integration module 112 may implement rules to determine mappings between the external code and the internal code. Examples of rules may include, but are not limited to: variable types such as doubles and floats may have a one-to-one mapping, integers by default map to integers but in some cases may map to fixed point types, enum types have a one-to-one mapping to a custom created model of enum type, struct types map to a custom created model of bus type, etc. The rules can be defined within the computing environment 100, defined by a user, or may be predetermined within the integration module 112, for example. The integration module 112 can use the rules to determine what semantic entities to map within the external code and how to map those semantic entities.
At 206, under-specified attributes associated with internal semantic entities that do not have corresponding specified attributes associated with the mapped external semantic entities are determined. The under-specified attributes may be associated with aspects of the identified external semantic entities which do not contain all of the information that would be needed by the internal semantic entities for use in the computing environment 100. For example, an under-specified attribute may be or include a function argument (e.g., an input argument, an output argument), a rate, a const, a reference, a type or structure, a state, a global variable, a pointer, or another element of an internal semantic entity which needs to be specified in order for the internal semantic entity to be usable in the computing environment 100.
A semantic entity from the external code may have one or more under-specified attributes. The under-specification associated with a given attribute may be caused by one of a number of occurrences. One example of an occurrence which causes an under-specification is the difference between the language capability of the external code and the language capabilities supported by the computing environment 100. In some cases, a mismatch that may lead to under-specification may occur if the semantic entities and attributes of those semantic entities of the native language(s) supported within the computing environment 100 are not supported by any given entity or attribute thereof from the external code. For example, the external code (e.g., C++ code) and internal code used within the computing environment 100 may both support double variables. However, the external code may not support fixed point integers, while the internal code used within the computing environment 100 does. In another example, the external code may include elements (e.g., Autosar component interface specification) expressing a time for code execution, but may not support the concept of sample rate used within the computing environment 100. There are a variety of ways in which the external code may be written that causes portions thereof to be under-specified within the computing environment 100. For example, a user-defined object or class within the external code may be written in a way (e.g., missing const specifiers on a class method even though the method may not have any side-effects) that prevents the integration module 112 from accurately parsing and mapping the external code.
The under-specified attributes can be determined by examining the external code, using metadata or other information indicative of known mismatches based on the language of the external code, and/or using metadata or other information indicative of prior executions of other external code having a similar under-specified attribute. Examining the external code can include or otherwise refer to the parsing and mapping operations described above. Alternatively, or additionally, examining the external code can include a manual examination of the external code. For example, a portion of the external code suspected to include an under-specified attribute can be flagged for user review. The metadata or other information indicative of the known mismatches, or of the prior executions of the other external code, can be metadata or other information which has been stored in a knowledgebase or other library of the computing environment 100. For example, metadata or other information may include a collection of file logs indicating the under-specified attributes determined within prior external code or indicating known entities or elements which cause mismatches within the computing environment 100. Metadata or other information may indicate that external code having a given format (e.g., a set of symbols with a certain structure) and under-specified attribute(s) can be mapped to a function with persistent state within the computing environment 100. Such metadata or other information can be used to determine that other external code having the same format is a same kind of under-specified attribute.
In some implementations, the mismatch takes place in situations in which the external code does not support programming capabilities of internal code of the computing environment 100 (e.g., forward declared incomplete types for pointers used in structures such as linked lists in external code). Identifying the mismatch can allow for the integration module 112 to prompt the user to make modifications to the exposed interface of the external code to make it digestible by the computing environment 100.
After identifying the set of under-specified semantic entities in the external code, the user may have a choice of accepting the default mapping by the integration module 112 or augmenting the default mapping by providing additional attributes to the integration module 112, for example, via a graphical user interface (dialog box) or command line API. At 208, available information for specifying attributes, such as at least some of the information characterizing the mapping of the external semantic entities to the internal semantic entities and/or at least some of the information characterizing the under-specified attributes determined based on the mapping, is provided to a user of the computing environment 100, for example, through a user interface system. The user interface system may be a system that includes a user interface through which communications may be enabled between a user of the computing environment 100 and an integration module thereof (e.g., the integration module 112). The information, or parts thereof, characterizing the under-specified attributes may be presented as the content of a window, for example, a prompt, delivered to the user of the computing environment 100. The information characterizing the under-specified attributes may indicate one or more options for the under-specified attributes.
For example, where the under-specified attribute is determined to be related to function argument mapping, the integration module may generate one or more options for specifying each of an input argument, an output argument, or a parameter of a function from the external code. The user receiving the information characterizing the under-specified attributes may, for each of the under-specified attributes, review the options and select the option that best classifies the under-specified attribute. In some implementations, where none of the options are appropriate, the user may be permitted to provide a custom response which differs from any of the presented options for the under-specified attribute.
In some cases, some of the options presented through the window may be read-only. For example, attributes of the internal semantic entity other than the under-specified attribute can be displayed in the window for the user to view, such as to assist with the selection of the option for resolving the under-specification or to otherwise report specified information for the internal semantic entity. For example, an attribute of a function which is understood to be an input argument may be presented as read-only. Furthermore, in some cases, the options presented through the window used to resolve the under-specification associated with the under-specified attribute may represent only a subset of the options determined by the integration module. That is, not all of the options for resolving the under-specification may be presented to the user for selection. For example, the integration module can use information about the task to be performed by the external code within the computing environment 100 to determine whether certain options are less probable for resolving the under-specification. The computing environment 100 may contain a dictionary of the various mapping options, which can be presented to the user to help with the mapping/augmentation of under-specified external code semantic entities.
At 210, internal semantic entities that may have been augmented using augmentation information determined based on a response to the information provided to the user interface system are stored. For the purpose of description, the response to the information provided to the user interface system may be referred to as response information. The response information represents the feedback of the user of the computing environment 100 for defining the uses and values of the under-specified attributes (e.g., a selection or specifying of under-specified attributes). The augmentation information may be or be generated based on the response information. Alternatively, where no response information is received in response to the information characterizing the under-specified attributes, the augmentation information may be or be based on predetermined information associated with the under-specified attributes. The predetermined information may be learned information, for example, obtained through prior mappings or user specifications which were used to resolve previously identified under-specified attributes. The predetermined information may be stored in the computing environment 100, within the external code, or in another location accessibly by the integration module for use in subsequent external code integration operations.
The augmentation information includes information in a form, e.g., symbolic and/or structural form, usable or supported by the computing environment 100 and corresponding to those under-specified attributes. The augmentation information can be specific to the type of the internal semantic entity. For example, where a function call from the external code is mapped to an internal semantic entity, without specifying a sample-rate for executing the function/making the function call , the augmentation information can indicate a specific rate for executing functions within the external code. The augmentation information would thus reflect how often the function is to be executed when used in the computing environment 100. In another example, wherein the external semantic entity is mapped to a pass-by-pointer argument, the augmentation information can indicate that the pointer points to an output argument. In some implementations, the internal semantic entities may be compiled with the augmentation information and the compiled code may be stored in a dynamic link library (DLL) file or another library.
The process 200 may end after step 210, which may occur before runtime, or the process may optionally perform one or more steps during runtime. Optionally, at 212, the augmentation information is used at a runtime of the internal program code that integrates external code. For example, the augmentation information may be stored as pointers or other references to specific portions of a library within a package (e.g., a DLL file or a shared object file). The package may further include a compiled or interpretable version of the external code. At runtime of the compiled or interpretable version of the external code, the computing environment 100 executes the internal code, which includes the internal semantic entities and uses the augmentation information (e.g., through pointers exported from the library within the package).
2 Simulation EnvironmentReferring again to
The packages/libraries 104 may be generated for the external code 106 after the external code 106 is integrated using the integration module 112. The packages/libraries 104 may include executable code representing an executable version (e.g., a compiled or interpretable version) of the external code 106. The packages/libraries 112 may further include interface information (e.g., in the form of data structures that are used by the computing environment 100 when a user thereof uses the integrated external code 106, noting, however, that the user of the computing environment 100 does not need to know of the external code 106 or otherwise use the external code 106 after the external code 106 has been integrated using the integration module 112. In some implementations, the packages/libraries 104 can be included in one or more libraries of the computing environment 100. In some implementations, the packages/libraries 104 can have a display component, for example, a graphical display such as a block, which is indiscernible from other native library components of the computing environment 100. For example, the interface information can be used at the runtime (e.g., during the simulation or code execution within the computing environment 100 or on hardware outside of the computing environment 100) of the compiled code to verify that the executed integrated code functions correctly (e.g., that the data types conform, the data ranges conform, etc.), and that the outputs are correctly captured.
In some implementations, internal semantic entities to which aspects of the external code 106 are mapped can be graphically represented as interface elements, e.g., graphical model elements/components, of the computing environment 100. For example, the computing environment 100 may include a graphical editor in which interface elements may be configured, such as to form user-identifiable icon (e.g., a graphical block or a textual icon). For example, the integration module 112, after integrating the external code 106, may additionally generate an interface element for a semantic entity mapped from the external code 106. The user of the computing environment 100 may use that generated interface element in the graphical editor of the computing environment 100.
In addition to the semantic, symbolic, and/or structural mapping and interface generation described above, in some implementations, the integration module 112 may also convert data storage formats between those used with the external code 106 and those used with internal code of the computing environment 100. For example, .cpp data types for external C++ code written in an environment that supports C++ development can be converted to .slx data types usable within the computing environment 100, .m data types usable within the computing environment 100, or other data types. In some implementations, the data type conversion is performed to implement in the computing environment 100, for example, a matrix majority scheme, a structure type padding scheme, or another scheme used for processing the external code. For example, if an OpenCV image is to be mapped to a computing environment 100 image of a different underlying format, data type conversion is implemented. In another example, if a user-defined entity (e.g., data, class, object, or another entity) in the external code 106 is to be mapped to an entity transparently handled (e.g., using pre-coded default rules for interpretation and execution) by the computing environment 100, the user may override the default rules by registering the conversion routines to convert the representation of the user-defined entity within the external code 106 to the domain-specific representation of the computing environment 100.
The computing environment 100 can enable various forms of simulation and/or modeling such as simulating real world systems represented by models which correspond to the program code 102, or analyzing certain behavior of those real world systems including time-domain and/or frequency domain behavior, and signal characteristics. Examples of such real world systems include, but are not limited to: systems that involve signal processing, such as those implemented in audio processing, image processing, video processing, or the like; communication systems, such as those implemented in telephone systems, network systems, mobile systems, other computer systems, or the like; control systems, such as those implemented in vehicles including cars, spacecraft, or the like; and physical systems, such as those implemented in machinery, circuits (e.g., electrical or otherwise), thermodynamic systems, or the like. At least some of the real world systems include hardware modules and software implemented on certain parts of the hardware modules for controlling those systems. At least some of the real world systems may be hardware modules within accompanying implemented software.
3 Exemplary Implementations within a Simulation Environment
The multiple functions in the external code of
The window 308 further includes a list of labels, types, and sizes for each of the four arguments. The mapping of the function edge_detection of the image processing routine 300 includes identifying labels of the arguments of that function which are used natively by the simulation environment, argument types of those arguments as used natively by the simulation environment, and sizes of those arguments as used natively by the simulation environment. The information identified by the mapping is extracted into the window 308 and populated in the appropriate locations. In the event that the expression of the function edge_detection of the image processing routine 300 within the external code shown in
Referring next to
The external code shown in the C programming language in
Mapping techniques using function argument mapping other than those described with respect to
In some implementations, the code generated for the integrated external code is in the form of a function call (e.g., a call site) to call the external code, which can be in the form of executable code or in source code form. Alternatively, the code generated for the integrated external code can include code that performs the functionality of the external code. The code generated in this alternative manner can be optimized with code generated for the native code in which the external code is integrated. In either situation, the improved or adapted code generator accesses and evaluates the mapping information and augmentation information. For example, the evaluation can include mapping an identified semantic entity or entity attribute within the native environment to the semantic entity or entity attribute within the external code. Such a mapping can be performed based on the mapping information, e.g., generated in the example shown in
Furthermore, as described previously, in some implementation, when the code generator has access to the source external code, the code generator may also generate code for the functionality of the external code, as opposed to merely a function call to the external code. The code generator can inline the source external code or regenerate the source external code that optimizes with other code that is generated for native program code.
An example of code 3004 generated for a model 3000 that integrates external code 3002 is shown in
As described above, function argument mapping may be at runtime or code generation. For example, user augmented function argument mapping information can be used during runtime and code generation to create a proper interface from a native user interface diagram, such as to call a particular C/C++ or other function. For an argument mapped to “input,” “output,” or “parameter,” a corresponding native buffer value may be passed to such function in the case where the argument is pass-by-value, or a corresponding native buffer address may be passed to such function in the case where the argument is pass-by-pointer. In the case where mapping is to both “input” and “output,” one input port and one output port of the same name may be created for the argument. The computing environment 100 may attempt to reuse the same buffer for both of the input and output ports. However, if the computing environment 100 is unable to do so, a full assignment from the input port buffer to the output port buffer is executed at runtime and at code generation. For an argument mapped to “constant,” the computing environment 100 may evaluate the user entered value expression and pass the resolved value directly to a C/C++ or other function at runtime, unlike at code generation in which the resolved value is hard coded in the generated function call statement. For pass-by-pointer or array arguments which are mapped to an “output” port, a full assignment to the output buffer array may be assumed, such as to enable certain code generation optimizations in a surrounding context.
For example, in
Examples of code, user interfaces, and/or models relating to the mapping of elements of a semantic entity to elements of an executable model using techniques other than those described with respect to
In some implementations, the environment 100 of
The workflow 1500 processes the external code for integration. At 1504, a header within external code is parsed. For example, the header may be a .h file of a C++ program written in an environment that supports C++ development. In another example, the header may be a file or document which includes external code written in a language that is not native to the computing environment within which the external code will be integrated. Parsing the header can reveal an under-specification in the form of missing information. Additionally, at 1506, analysis can be performed to identify where such information may be missing (e.g., under-specified attributes of an internal semantic entity) based on the parsed header or other portions of parsed external code. The missing information may reflect an under-specification resulting from a mapping of the external code to elements of the computing environment. The missing information can be identified by comparing known elements from the external code to known elements of a model of the computing environment and determining the elements of the external code which do not have known corresponding elements within the model of the computing environment. In particular, the missing information may refer to one or more elements of the external code which are not specified to the computing environment and which require specification in order for the external code to be used to perform a given task. Examples of missing information can include missing shape (e.g., dimensionality and/or size) of a data value or a missing direction of a function argument in the example of C++ headers/header files for functions integrated into MATLAB, and missing rate or scaling information in the example of C++ headers/header files for functions integrated into Simulink. At 1508, a user interface is presented that describes the elements of the external code and prompts the user for the identified missing information. For example, the user interface presented can include a window (e.g., the window 308) which shows the elements of a semantic entity identified by parsing and mapping the external code, along with a list of options which may be selected by the user to provide the missing information. At 1510, the user updates the internal code which has mapped to the external code (e.g., the internal semantic entity) to indicate the missing information. The information provided by the user is stored as augmentation information in connection with the internal semantic entity, such as for later use in executing the internal code which now integrates the external code.
The workflow 1502 generates and publishes an interface library for the external code integrated with the internal code of the computing environment using, e.g., the workflow 1500. At 1512, metadata is collected and/or generated. For example, metadata previously generated by the workflow 1500 may include a set of mappings from external semantic entities to internal semantic entities. The metadata may have come into existence at any of a variety of steps in the workflow 1500, including at the end of 1504 or 1506, optionally updated at 1510 by the user through internal code/graphical elements. At 1514, optionally, external code that may be executed at runtime, along with any generated internal code, may be generated or otherwise received, for example, from an environment external to the computing environment 100 (e.g., the external environment 108). At 1516, the interface library is built to link to an original library used by the internal code of the computing environment 100, and which interface library includes the metadata created by the integration module 112. The interface library may, for example, be a DLL which includes the internal code of the computing environment 100 to which the external code is mapped along with augmentation information produced to resolve under-specifications within the external code. Building the DLL may optionally include updating a variety of data structures and/or files for internal code based on the metadata. At 1518, the interface library is published for use within the computing environment 100. The interface library may be selected for use within the computing environment 100 by including a call to the interface library, or a semantic entity within the interface library, within internal code, for example. Alternatively, the interface library may be selected for use within the computing environment 100 by including a graphical block representing the interface library within a graphical model of the computing environment.
The workflows 1500 and 1502 can enable easy integration and usage of external code, e.g., code from a non-technical computing environment or a different technical computing environment within the computing environment 100. For example, rather than requiring a user to manually manage memory and pointer usage when integrating external code, the workflows 1500 and 1502 offer options for automated user-guided integration. In this way, the user does not need to work with arrays of unknown sizes from the external code, thereby reducing the amount of memory that will be used to provide the missing information for the integration. Furthermore, the computing environment 100 becomes better suited to handle exceptions and compiler incompatibilities arising from the use of the external language of the external code within the computing environment 100.
In another example, the user-provided information used to resolve an under-specification can produce an interface library which is effective for executing the external code based on a best guess as to how to resolve any under-specification. The interface library can provide improved mapping of language attributes, improved lifecycle management practices, and renaming practices. In yet another example, an interface library can include all of the entry points that the internal semantic entity integrated with the external code uses for execution, along with the metadata used to understand how those entry points are used and exposed within the computing environment.
Calls to internal functions addFunction( ) and defineArgument( ) can be generated, for example, after parsing the external code. The internal function addFunction( ) is used (e.g., by the integration module 112) to map the function foo (as an external semantic entity) to a corresponding function (as an internal semantic entity). The internal function defineArgument( ) is used (e.g., by the integration module 112) to specify an under-specified attribute, which in this example is the direction of the input argument “input1”. The direction is defined as “inputoutput” in this example, which has no equivalent attribute in the external language. Available information may be presented to a user in a prompt for selecting or specifying the correct value (e.g., “inputoutput”) for the under-specified direction attribute.
Referring next to
Referring next to
Referring next to
Referring next to
Referring next to
Referring next to
Referring next to
Information written into documentation accompanying external code (e.g., within an .arxml file or the like) can be parsed and mapped to help resolve under-specifications. For example, a developer of the external code may understand that the external code is written in a language that is not supported by the computing environment 100. To assist with mapping some or all of the external code, the developer or another user can indicate how those portions of the external code should be mapped into the computing environment 100.
That is, a computing environment that processes external code may process information captured from documentation associated with the external code. The captured information may then be added to definitions of semantic entities and available to users of the computing environment 100, for example, within a library available to the computing environment 100. Alternatively, or additionally, the captured information may be added to definitions of semantic entities within other documentation available to the user, such as to assist the user with his or her use and operation of the computing environment 100. The documentation processing can thus be provided to capture documentation which is intended to not be used in the computing environment 100 or in an environment of a language of external code related to the documentation and present the captured documentation for use in connection with the computing environment 100.
For example, the external code may include entities which map to an internal semantic entity of a rate type within the computing environment 100. Documentation related to the external code (e.g., included in an .arxml file or the like) may be received at the computing environment 100 along with the external code. The documentation may include comments or other information about the functions and other semantic entities within the external code. For example, “interface_fcn_1(int16u)” refers to a semantic entity of C++ code and is already included in a C/C++ library. However, the user can add information within a corresponding .arxml file to specify “rate: 0.1” for indicating the rate for executing that semantic entity. Alternatively, the user can add information within the .arxml file to specify that the argument type used by that semantic entity should be different. For example, the argument “int16u” may be understood in C to refer to an integer type; however, the user can specify “fixdt(1,16,3)” within the .arxml file to indicate that the argument “int16u” should be mapped to a fixed point type in the computing environment 100.
Such exemplary documentation processing may first include capturing source code comments that follow a pattern associated with documentation. For example, the comments may follow the rules for doxygen, javadoc, or another comment scheme used within an external code source environment. The source code comments may thus be identified as being associated with a particular semantic entity based on their locations within the source code and/or with reference to symbols nearby those comments within the external code files. In some cases, such as where it is difficult to determine that a source code comment is associated with a particular semantic entity based on the location of the comments within the external code or nearby symbols, a search may be performed for references to names of semantic entities within the comment itself.
Next, documentation associated with the external code or a source or development environment thereof may be augmented using the captured source code comments. In this way, the augmented documentation becomes usable for the computing environment 100. Augmenting the documentation may, for example, include one or more of changing names of the semantic entities when the name of the semantic entity used in the computing environment 100 differs from what is written in the source code comment, detecting other code examples based on tags or markdown usage indicating a possible example use of the semantic entity, and detecting code examples by applying a source language parser to the comment and finding fragments that may be parsed.
After the documentation is augmented, mappings for standard syntax of the source code comment may be identified to cause the use of the source code comment to be associated with the internal language syntax. In some cases, such as where it may be difficult to determine a precise mapping for the source code comment, the example in the source syntax may remain, but with an indication that the example is in the source language syntax. In such a case, a link to documentation may be created and used to guide the end user to mapping the source code comment into the computing environment 100. In some implementations, standard syntax for comments can include widely used industry standards such as “doxygen” or “javadoc style” comments. The doxygen documentation can also be found at https://doxygen.nl. In some implementations, documentation standards provide special tags or other ways to indicate or mark example code. When those indicators or markers are seen, the code in the example can be parsed as C or C++ code and the parsed constructs can be converted to code for computing environment 100 using a map between the syntax of identified language constructs from the source language into computing environment 100. For example, a “X->Y” construct might be turned into a “X.Y” construct. Another example of a mapping is from variable declarations that include a type to simply naming the variable. Thus, code of the form “<type><varname>=<expression>” are translated into “<varname>=<expression>.” Another example is as follows:
-
- auto X=new MyClass( );
- double Y=X->getValue( );
which may be translated into: - X=MyClass( );
- Y=X.getValue( );
For examples of indicators or markers, doxygen defines a tag “\example” that is used to specify a file path to a code file that contains an example. This example is inserted into documentation by the doxygen system. When finding this tag, the code file can be located and parsed as code in the source language and then translated into the language of computing environment 100 as described above.
In some implementations, a publisher of the documentation may be given permissions to edit the documentation after it is augmented. In some implementations, a machine learning approach (e.g., using deep learning algorithms) may be applied to enable the computing environment to learn from publisher edits, such as to automate the mapping of comments for use within the computing environment 100. The following is an example using C++ syntax:
In MATLAB, the function may be renamed to “findCorners” using the definition file, e.g., using systems and methods described above.
The following example shows C++ code that can be converted or integrated to MATLAB code.
The simulation engine 2412 may include an interpreter 2416, a parser 2418, a model compiler 2420, and one or more solvers, such as solvers 2422a-c. The model compiler 2420 may include one or more Intermediate Representation (IR) builders, such as IR builder 2424. In some implementations, one or more IR builders may be included or associated with the solvers 2422. The simulation engine 2412 may execute, e.g., compile and run or interpret, computer-generated, executable models using one or more of the solvers 2422a-c. For example, the solvers 2422 may generate a set of equations for a model and may solve the set of equations. Another approach would be for the model compiler 2420 to create a data structure that represents, for example, model equations, and the solvers 2422 then use this data structure to generate solutions. For example, the solvers 2422 may generate a solution for an in-memory, intermediate representation (IR) of a model that represents a set of computational operations. The solvers 2422 may generate the solution for the IR using numerical techniques. Exemplary solvers include one or more fixed-step continuous time solvers, which may utilize numerical integration techniques, and one or more variable-step solvers, which may for example be based on the Runge-Kutta and Dormand-Prince pair. With a fixed-step solver, the step size remains constant throughout simulation of the model. With a variable-step solver, the step size can vary from step to step, for example to meet error tolerances. A non-exhaustive description of suitable solvers may be found in the Simulink User's Guide from The MathWorks, Inc. (March 2017 ed.). There may also be solvers to solve algebraic relations and solvers to find zero crossing locations of indicator functions. These solvers may have particular application in physics models.
The code generator 2408 may access a model, such as model 2430, and may generate code, such as code 2432, for the model 2430. In some implementations, the generated code may be source code, which may be compiled by the compiler 2410, and executed by one or more processors outside of the simulation environment 2400, or executable code, or other types of code. The generated code may thus be standalone code relative to the simulation environment 2400. Examples of generated code include Ada, Basic, C, C++, C#, CUDA, SystemC, Ada, FORTRAN, assembly code, and Hardware Description Language (HDL) code, such as VHDL, Verilog, or SystemC, among others, which may be used to synthesize a programmable logic device.
The compiler 2410 may prepare data structures and evaluate parameters, or parameter expressions, to create and/or initialize one or more data structures used in a compile stage. For each element, a method may force the element to evaluate all of its parameters. During the configuration and inferencing, for example by propagation, of element and port/signal characteristics, the compiled attributes (such as data dimensions, data types, complexity, sample modes, and sample time) of each element (and/or ports) may be setup on the basis of the corresponding behaviors and the attributes of elements (and/or ports) that are related to the given element, e.g., connected through lines that may be undirected relations or directed relations and shown as arrows. Attributes may also be setup based on the context of an element or a component in a model. For example, a subsystem, which may be a group of elements hierarchically represented as a single element, that has a given sample time may have this sample time be set based on the sample time of elements included in the subsystem (e.g., a unique sample time of all elements in the group or a base sample time such as the greatest common denominator of all sample times of the elements).
The attribute setup may be performed through a process during which element behaviors “ripple through” the model from one element to the next following signal or other connectivity, as well as through the hierarchical structure of the model, and may for example follow connectivity in a forward or backward manner. This process is referred to as “propagation.” In the case of an element that has explicitly specified or characterized its element behaviors or the behaviors of its ports, propagation may help ensure that the attributes of the element are compatible with the attributes of the elements connected to it or contained by it. If not, an error may be issued. At least some elements may be implemented to be compatible with a wide range of attributes. Such elements may adapt their behavior in accordance with the attributes of the elements connected to them. The exact implementation of the element may be chosen on the basis of the model in which the element is located. Included within this step are other aspects such as validating that all rate-transitions (e.g., transitions of sample times that have different rates between two connected elements) yield deterministic results, and that the appropriate rate transition blocks are being used.
The compilation step also may determine element connectivity. For example, a model may include one or more virtual blocks that may play no semantic role in the execution of the model. In this step, the virtual blocks may be optimized away, e.g., removed, and the remaining non-virtual elements may be reconnected to each other appropriately. This compiled version of the model with actual element connections may be used from this point forward in the execution process.
Exemplary computing environments which may be the computing environment 100 described herein include the MATLAB® language/programming environment and the Simulink® model-based simulation and design environment. Alternatively, the computing environment 100 may refer to exemplary systems or tools used by such computing environments, which may be the Simscape™ physical modeling system, the SimEvent® discrete-event modeling tool, and the Stateflow® state chart modeling tool also from The MathWorks, Inc. Models created in the high-level computing environment may contain less implementation detail, and thus operate at a higher level than certain programming languages, such as the C, C++, C#, and SystemC programming languages.
A given model may simulate, for example, approximate the operation of, a system. Exemplary systems include physical systems, such as plants and controllers. A model may be executed in order to simulate the system being modeled, and the execution of a model may also be referred to as simulating the model. Models constructed within the simulation environment 2400 may include textual models, graphical models, such as block diagrams, state-based models, discrete-event models, physical or physics models, noncausal (or acausal) models (e.g., implicit equation based models), equation-based models, object-oriented models, and combinations thereof. A graphical model may include icons or blocks that represent computations, functions, or operations, and interconnecting lines or arrows among the blocks may represent data, signals, or relationships among those computations, functions, or operations. The icons or blocks, moreover, may be selected by the user from one or more of the libraries or palettes that contain icons or blocks for the blocks supported by the simulation environment 2400. A model editor GUI may include a Run button that may be selected by the user. The simulation environment 2400 may also be configured to receive a run command entered by the user, e.g., in the GUI or in a Command Line Interface (CLI). In response to the user selecting the Run button or entering the run command, the simulation engine 2412 may execute the model, and may present the results of the model's execution to a user. Exemplary graphical models include Simulink models, Simscape physical models, SimEvent models, Stateflow charts, LabVIEW block diagrams, MatrixX models, Scade models, Dymola models, VEE diagrams, and Rational Rhapsody models, among others. Other forms of a source program include Modelica models from the Modelica Association, Uniform Modeling Language (UML) models, and Systems Modeling Language (SysML) models, among others.
In some implementations, the simulation environment 2400 may implement a declarative language. A declarative language is a language that expresses the logic of a computation without describing its control flow. A declarative language may describe what a program must accomplish in terms of the problem domain, rather than describe how to accomplish it as a sequence of the programming language statements. In some cases, a declarative language may implement single assignment in which variables are assigned once and only once. Examples of support for declarative languages include the Simulink® model-based design environment, which is a time-based language, the Modelica modeling language, and the LabVIEW graphical programming system, Hardware Description Language (HDL), the Prolog language, and the Haskell language, among others. Behaviors of at least some of the elements and connection elements of a model may include computational implementations that are implicitly defined by a declarative language. The simulation environment 2400 may also support constraint modeling (or graphical constraint programming), for example, as supported by Simulink.
The simulation environment 2400 is intended for illustrative purposes and that the present disclosure may be used with other computing environments. For example, in some implementations, the code generator 2408 and/or the compiler 2410 may be separate from the simulation environment 2400.
One or more of the user interface engine 2402, the model editor 2404, the code generator 2408, the compiler 2410, and the simulation engine 2412 may be implemented through one or more software modules or libraries containing program instructions that perform the methods described herein. The software modules may be stored in a memory, such as a main memory, a persistent memory and/or a computer readable media, of a workstation, server, or other data processing machine or device, and executed by one or more processors. Other computer readable media may also be used to store and execute these program instructions, such as non-transitory computer readable media, including optical, magnetic, or magneto-optical media. In some implementations, one or more of the user interface engine 2402, the model editor 2404, the code generator 2408, the compiler 2410, and the simulation engine 2412 may comprise hardware registers and combinational logic configured and arranged to produce sequential logic circuits. In some implementations, various combinations of software and hardware, including firmware, may be utilized to implement the described methods.
Suitable code generators for use with the present disclosure include, but are not limited to, the Simulink Coder, the Embedded Coder, and the Simulink HDL Coder products from The MathWorks, Inc. of Natick, MA, the TargetLink product from dSpace GmbH of Paderborn Germany, and QGen from Adacore. Suitable internal language compilers include the xPC Target™ tool from The MathWorks, Inc., and a C language compiler. However, other code generation systems and other compilers may be used.
The client device 2502 may include a device capable of receiving, generating, storing, processing, executing, and/or providing information, such as information associated with program code 102. For example, the client device 2502 may include a computing device, such as a desktop computer, a laptop computer, a tablet computer, a handheld computer, a server, a mobile phone (e.g., a smart phone, a radiotelephone, or the like), or a similar device. In some implementations, the client device 2502 may receive information from and/or provide information to the server device 2506.
The client device 2502 may host the computing environment 2504. Functions described herein as being performed by the computing environment 2504 may be performed by the client device 2502 and execution of the computing environment 2504 by the client device 2502. For example, the computing environment 2504 may be or include computing environment 100. The computing environment 2504 may provide mathematical functions and/or graphical tools (e.g., for creating plots, surfaces, images, volumetric representations, or the like). In some implementations, the computing environment 2504 may provide these functions and/or tools using toolboxes (e.g., toolboxes for signal processing, image processing, data plotting, parallel processing, or the like). In some implementations, the computing environment 2504 may provide these functions as block sets or in another way, such as via a library, a local or remote database (e.g., a database operating in a computing cloud), remote procedure calls (RPCs), an API, or the like.
The computing environment 2504 may include a modeling system that may be used in the creation of a functional model and that may enable generation of executable code based on the model. For example, the computing environment 2504 may include a graphical modeling tool or application that provides a user interface for a numerical computing environment. Additionally, or alternatively, the computing environment 2504 may include a graphical modeling tool and/or application that provides a user interface for modeling and simulating (e.g., by executing a model) a dynamic system (e.g., based on differential equations, difference equations, discrete events, discrete states, or the like). Execution of a model to simulate a system may also be referred to as simulating a model. The model may further include static relations (e.g., algebraic relations, stochastic relations, inequalities, or the like). In some implementations, the model may include different types, such as data flows, differential equations, difference equations, time-based block diagrams, state transition diagrams, entity flow diagrams, signal flow diagrams, discrete event systems, object diagrams, physical modeling diagrams, or the like.
The server device 2506 may include one or more devices capable of receiving, generating, storing, processing, and/or providing information, such as information associated with a model. For example, the server device 2506 may include a computing device, such as a server, a desktop computer, a laptop computer, a tablet computer, or a similar device. In some implementations, the server device 2506 may host the computing environment 2504. In some implementations, the client device 2502 may be used to access the computing environment 2504 running on one or more server devices 2506. For example, the multiple server devices 2506 may be used to execute code (e.g., serially or in parallel), and may provide respective results of executing the code to the client device 2502.
In some implementations, the client device 2502 and the server device 2506 may be owned by different entities. For example, an end user may own the client device 2502, and a third party may own the server device 2506. In some implementations, the server device 2506 may include a device operating in a cloud computing environment. In this way, front-end applications (e.g., a user interface) may be separated from back-end applications (e.g., code execution). Additionally, or alternatively, the server device 2506 may perform one, more, or all operations described elsewhere herein as being performed by the client device 2502.
The network 2508 may include one or more wired and/or wireless networks. For example, the network 2508 may include a cellular network, a public land mobile network (PLMN), a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a telephone network (e.g., the Public Switched Telephone Network (PSTN)), an ad hoc network, an intranet, the Internet, a fiber optic-based network, a private network, a cloud computing network, and/or a combination of these or other types of networks.
The number and arrangement of devices and networks shown in
The processor 2604 is implemented in hardware, firmware, or a combination of hardware and software. The processor 2604 may include a processor (e.g., a central processing unit (CPU), a graphics processing unit (GPU), an accelerated processing unit (APU), or the like), a microprocessor, and/or any processing component (e.g., a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), or the like) that interprets and/or executes instructions, and/or that is designed to implement one or more computing tasks. In some implementations, the processor 2604 may include multiple processor cores for parallel computing.
The memory 2606 may include a random access memory (RAM), a read only memory (ROM), and/or another type of dynamic or static storage device (e.g., a flash memory, a magnetic memory, an optical memory, or the like) that stores information and/or instructions for use by the processor 2604.
The storage component 2608 may store information and/or software related to the operation and use of device 2600. For example, the storage component 2608 may include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optic disk, a solid state disk, or the like), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cartridge, a magnetic tape, and/or another type of computer-readable medium, along with a corresponding drive. In some implementations, the storage component 2608 may store data used to implement a computing environment, such as the computing environment 2504.
The input component 2610 may include a component that permits the device 2600 to receive information, such as via user input (e.g., a touch screen display, a keyboard, a keypad, a mouse, a button, a switch, a microphone, or the like). Additionally, or alternatively, the input component 2610 may include a sensor for sensing information (e.g., a global positioning system (GPS) component, an accelerometer, a gyroscope, an actuator, or the like). The output component 2612 may include a component that provides output information from the device 2600 (e.g., a display, a speaker, one or more light-emitting diodes (LEDs), or the like).
The communication interface 2614 may include a transceiver-like component (e.g., a transceiver, a separate receiver and transmitter, or the like) that enables device 2600 to communicate with other devices, such as via a wired connection, a wireless connection, or a combination of wired and wireless connections. The communication interface 2614 may permit the device 2600 to receive information from another device and/or provide information to another device. For example, the communication interface 2614 may include an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.
The device 2600 may perform one or more processes described herein. The device 2600 may perform these processes in response to the processor 2604 executing software instructions stored by a computer-readable medium, such as the memory 2606 and/or the storage component 2608. A computer-readable medium is defined herein as a non-transitory memory device. A memory device includes memory space within a single physical storage device or memory space spread across multiple physical storage devices.
Software instructions may be read into the memory 2606 and/or the storage component 2608 from another computer-readable medium or from another device via the communication interface 2614. When executed, software instructions stored in the memory 2606 and/or the storage component 2608 may cause the processor 2604 to perform one or more processes described herein. Additionally, or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.
The number and arrangement of components shown in
The headings above are intended to aid with readability of the application, and are not for use in construing aspects of, or determining the breath of, implementations of the invention described in the specification or claims. It is to be understood that the foregoing description is intended to illustrate and not to limit the scope of the invention, which is defined by the scope of the appended claims. Other implementations are within the scope of the following claims.
Claims
1. A computing system for processing external code that is not native to a computing environment, the computing system comprising:
- a processing system, including at least one processor, configured to process the external code, the processing including: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, wherein the first attribute of the second set of one or more attributes comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior, determining available information for specifying the first attribute of the second set of one or more attributes, providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
2. (canceled)
3. The computing system of claim 1, wherein the processing further comprises: generating a user interface element for the second semantic entity; and storing the user interface element in a library of the computing environment, or using the user interface element in program code developed in the computing environment.
4. The computing system of claim 3, wherein the user interface element comprises a graphical element in a graphical programming canvas environment, or a textual symbol callable from the computing environment.
5. (canceled)
6. The computing system of claim 1, wherein the processing further comprises debugging the first entity using the second semantic entity in the computing environment.
7. The computing system of claim 1, wherein the processing further comprises generating code for the first entity using the second semantic entity.
8. (canceled)
9. The computing system of claim 1, wherein the processing further comprises performing cross-domain optimization across the first and second semantic entities, and the cross-domain optimization comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
10. The computing system of claim 1, wherein the second semantic entity comprises: a named function associated with at least one input parameter or output parameter, a named variable associated with storage of a corresponding type, a named semantic category associated with a class or service, a keyword associated with a type of a variable or parameter or associated with functionality for a semantic entity, a rate, a constant, a reference, a type, a structure, a state, or a service port.
11. The computing system of claim 1, wherein the first semantic entity comprises: an entity in a language comprising C, C++, C#, CUDA, SystemC, Java, FORTRAN, Python, Visual Studio, HDL, VHDL, or Verilog; or an entity in a platform comprising OpenCV, AWS SDK for C++, OpenDDS, ZeroMQ, Qt, Halide, TensorFlow C++ API, Pytorch C++ API, Caffe, CImg, Libtiff, Crypto++, Tesseract, FreeImagePlus, LibXL, Tonic, or Botan, OpenCV, OpenDDS, or Tensorflow.
12. The computing system of claim 1, wherein the processing further comprises integrating documentation associated with the first semantic entity into documentation associated with the second semantic entity.
13. A method for processing external code that is not native to a computing environment, the method comprising:
- parsing the external code to identify a first semantic entity,
- mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified,
- determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, wherein the first attribute of the second set of one or more attributes comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior,
- determining available information for specifying the first attribute of the second set of one or more attributes,
- providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and
- storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
14. The method of claim 13, further comprising: generating a user interface element for the second semantic entity; and storing the user interface element in a library of the computing environment, or using the user interface element in program code developed in the computing environment.
15. The method of claim 14, wherein the user interface element comprises a graphical element in a graphical programming canvas environment, or a textual symbol callable from the computing environment.
16. (canceled)
17. One or more non-transitory computer-readable media, having stored thereon instructions for processing external code that is not native to a computing environment, where the instructions, when executed by a computing system, cause a computing system to perform operations comprising:
- parsing the external code to identify a first semantic entity,
- mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified,
- determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, wherein the first attribute of the second set of one or more attributes comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior,
- determining available information for specifying the first attribute of the second set of one or more attributes,
- providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and
- storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying.
18. The one or more non-transitory computer-readable media of claim 17, wherein the operations further comprise: generating a user interface element for the second semantic entity; and storing the user interface element in a library of the computing environment, or using the user interface element in program code developed in the computing environment.
19. The one or more non-transitory computer-readable media of claim 18, wherein the user interface element comprises a graphical element in a graphical programming canvas environment, or a textual symbol callable from the computing environment.
20. (canceled)
21. A method comprising:
- generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising:
- identifying a semantic entity of the fifth code,
- mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code, wherein the at least one attribute of the of the semantic entity of the fifth code comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior, and
- generating the second code based on the mapping the semantic entities of the fifth code and the fourth code.
22. The method of claim 21, wherein generating the second code comprises generating a function call to the fourth code.
23. The method of claim 22, wherein generating the second code comprises generating code for the third code and including the function call with the code generated for the third code.
24. The method of claim 21, wherein generating the second code comprises in-lining the fourth code in the generated second code.
25. The method of claim 21, wherein the fourth code comprises: code in a language comprising C, C++, C#, CUDA, SystemC, Java, FORTRAN, Python, Visual Studio, HDL, VHDL, or Verilog; or code in a platform comprising OpenCV, AWS SDK for C++, OpenDDS, ZeroMQ, Qt, Halide, TensorFlow C++ API, Pytorch C++ API, Caffe, CImg, Libtiff, Crypto++, Tesseract, FreeImagePlus, LibXL, Tonic, or Botan, OpenCV, OpenDDS, or Tensorflow.
26. A computing system comprising:
- a processing system, including at least one processor, configured to process the external code, the processing including: generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising: identifying a semantic entity of the fifth code, mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code, wherein the at least one attribute of the of the semantic entity of the fifth code comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior, and generating the second code based on the mapping the semantic entities of the fifth code and the fourth code.
27. One or more non-transitory computer-readable media, having stored thereon instructions that, when executed by a computing system, cause a computing system to perform operations comprising:
- generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising:
- identifying a semantic entity of the fifth code,
- mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code, wherein the at least one attribute of the of the semantic entity of the fifth code comprises: a fixed point datatype, a sample rate, a unit, an input or output scope, a complexity, an attribute indicating pass-by-reference or pass-by-value, an attribute indicating read-before-write or write-before-read, an attribute indicating a mutable or immutable property, an attribute indicating a side-effect-full or side-effect-free nature of a function, array or matrix dimensions, a thread-safety property, or an exception throwing behavior, and
- generating the second code based on the mapping the semantic entities of the fifth code and the fourth code.
28. A computing system for processing external code that is not native to a computing environment, the computing system comprising:
- a processing system, including at least one processor, configured to process the external code, the processing including: parsing the external code to identify a first semantic entity, mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified, determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes, determining available information for specifying the first attribute of the second set of one or more attributes, providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying, and performing an operation associated with the first and second semantic entities, wherein the operation comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
29. A method for processing external code that is not native to a computing environment, the method comprising:
- parsing the external code to identify a first semantic entity,
- mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified,
- determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes,
- determining available information for specifying the first attribute of the second set of one or more attributes,
- providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes,
- storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying, and
- performing an operation associated with the first and second semantic entities, wherein the operation comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
30. One or more non-transitory computer-readable media, having stored thereon instructions for processing external code that is not native to a computing environment, where the instructions, when executed by a computing system, cause a computing system to perform operations comprising:
- parsing the external code to identify a first semantic entity,
- mapping the first semantic entity to a second semantic entity associated with the computing environment, the first semantic entity comprising a first set of one or more specified attributes and the second semantic entity comprising a second set of one or more attributes that are capable of being specified,
- determining that at least a first attribute of the second set of one or more attributes does not have a corresponding specified attribute within the first set of one or more specified attributes,
- determining available information for specifying the first attribute of the second set of one or more attributes,
- providing the available information to a user interface system for providing to a user for selection or specifying the first attribute of the second set of one or more attributes, and
- storing the second semantic entity in association with the first attribute of the second set of one or more attributes specified based on the user selection or specifying, and
- performing an operation associated with the first and second semantic entities, wherein the operation comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
31. A method comprising:
- generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising:
- identifying a semantic entity of the fifth code,
- mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code,
- generating the second code based on the mapping the semantic entities of the fifth code and the fourth code, and
- generating code to perform an operation associated with the semantic entities of the fifth code and the fourth code, wherein the operation comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
32. A computing system comprising:
- a processing system, including at least one processor, configured to process the external code, the processing including: generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising: identifying a semantic entity of the fifth code, mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code, generating the second code based on the mapping the semantic entities of the fifth code and the fourth code, and generating code to perform an operation associated with the semantic entities of the fifth code and the fourth code, wherein the operation comprises:
- inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
33. One or more non-transitory computer-readable media, having stored thereon instructions for processing external code that is not native to a computing environment, where the instructions, when executed by a computing system, cause a computing system to perform operations comprising:
- generating second code for first code that includes third code that is native to a computing environment and fourth code that is external to the computing environment, the fourth code being integrated and represented by fifth code native in the computing environment, and the generating comprising:
- identifying a semantic entity of the fifth code,
- mapping the semantic entity of the fifth code to a semantic entity of the fourth code based on a mapping from the semantic entity of the fourth code to the semantic entity of the fifth code, the mapping comprising determining that a corresponding attribute of at least one attribute of the semantic entity of the fifth code does not exist or is to be underspecified in the semantic entity of the fourth code,
- generating the second code based on the mapping the semantic entities of the fifth code and the fourth code, and
- generating code to perform an operation associated with the semantic entities of the fifth code and the fourth code, wherein the operation comprises: inlining, data copy minimization, retargetable code generation, static analysis, property proving, modified condition/decision coverage (MC/DC), decision coverage, test vector generation, report generation, requirements linking, certification checking, continuous integration (CI) tool support, or identification or merging of differences.
Type: Application
Filed: May 31, 2019
Publication Date: Dec 3, 2020
Inventors: Vivek Bhownani (Ashland, MA), Alexander C. Feinman (Waltham, MA), Fazil Peermohammed (Holliston, MA), David A. Foti (Holliston, MA), Ebrahim Mehran Mestchian (Newton, MA), Yao Ren (Sudbury, MA), Vijaya Raghavan (Brookline, MA), Peter S. Szpak (Newton, MA), Matthew Englehart (Valley City, OH), Roy Mathew (Mansfield, MA), Emmanuel Roy (Les Loges En Josas), Dekun Pei (Marlborough, MA), Jianhao Du (Framingham, MA), Antoine Requet (Sevres), Shailesh Shashikant Nirgudkar (Acton, MA)
Application Number: 16/428,445
