 | Processor Options - One option for each supported StarCore model. This setting determines the instructions permitted, as well as the pipeline optimization strategy used. |
|
| Constant Data Section - Places all string literals, constants, and initialized variables declared const in C and C++ in a distinct section. |
|
| VLES Packing - The StarCore uses
variable length execution sets (VLES), which are VLIW-like groupings of instructions. The StarCore compiler can reorder instructions to maximize VLES packing according to the rules of the specific StarCore model being compiled. |
|
| Zero Data Area - The StarCore compiler can access data stored at an arbitrary 32-bit address with a single 48-bit instruction. However, to minimize code size, and to increase the VLES packing opportunities, the StarCore compiler can collect frequently accessed data into a 64k block that is located in the low 16-bits of address space. This data can be accessed with a single 32-bit instruction.
|
|
| Software Pipelining - The StarCore compiler supports the software pipelining optimization on loops with both constant and variable bounds. The compiler detects when software pipelining will decrease the per-iteration cycle count, and performs the optimization.
|
|
| Hardware Loop Support - The StarCore compiler can generate nested hardware loops up to four levels deep.
|
|
| ETSI Intrinsic Functions - The StarCore compiler supports a large number of ETSI intrinsic functions to allow the user fine control over fractional arithmetic. The intrinsic functions are recognized by the compiler, and StarCore code, often a single instruction, is inlined. The resulting instructions can be fully optimized by the compiler.
|
| Run-Time libraries |
| A comprehensive suite of run-time libraries for C and C++ are included in the compiler distribution. Several different versions of the libraries are provided to accommodate different combinations of processor and memory models, including big Endian vs. little Endian memory models. Full featured start-up code and libraries include automatic copy of data from ROM to RAM and system call emulation. Source code to the run-time libraries is available so that users can customize routines according to the special needs of their applications. |
| The MULTI Integrated Development Environment |
MULTI provides a host-based (Windows 9x/NT/2000/2000 PC or UNIX workstation) graphical environment for
StarCore target development. Host-target connectivity is provided through a variety of means, depending on the target
environment. MULTI supports the SDP evaluation board which can be accessed with a variety of interfaces:
|
Bare Board Access (No RTOS or ROM Monitor) - MULTI connects to boards that offer a JTAG debugging interface. MULTI provides a complete software package that enables programmers to debug code without need for operating systems, kernels, or even ROM monitors. |
|
Commercial RTOS Support - MULTI supports StarCore boards running RTXC from Embedded Power Corporation, and provides multitask-aware debugging. |
|
Custom RTOS Support - MULTI can be integrated with a custom RTOS through the Green Hills INDRT API. INDRT provides all the debug information needed by MULTI, and is easily integrated into custom kernel code. |
|
Instruction Set Simulator - The Simsc instruction set simulator interpretively executes StarCore programs on the host PC or UNIX workstation without the requirement of target hardware by simulating the execution of the target processor at the instruction level. Simsc provides full debug features, host I/O, command window, extended profiling and hardware break-points. Simsc also simulates target CPU cache for those processors which support it. |
|
| Data Visualization |
MULTI's Data Visualization enables the user to select source code variables in the debugger and view their numerical data in a wide range
of graphical formats without changing the application code.
Servers exist for a built-in MULTI display package and industry-leading packages such as MATLAB. Displays are evoked through MULTI's
source level debugger and are updated by breakpoint events or updated in real-time through dynamic data capture and management. |
)
