Q. What environment variables can control the execution of IAS?
The following are the environment variables that IAS looks for:
DSVHOME: Not used by the backend, but used by IAS or MFS front-ends to load trap handlers from$DSVHOME/class/predefined_class_names.classand to locate the TCL front-end shell from$DSVHOME/etc/sim/sim.tcl.
PICOJAVA_MEMORY_SIZE: Sets the size of the "common memory." Has to be set to the size of the memory required in Mbytes. For example, either of:
setenv PICOJAVA_MEMORY_SIZE 24
setenv PICOJAVA_MEMORY_SIZE 0x18sets the size of the memory to 24MB. If the variable is not set, or is set incorrectly, reverts to the default value (typically 16 Mbytes).
This does not affect the "scratch" area. The size of the main memory should not be set such that it overruns the scratch area.
This environment variable is applicable to both RTL and ias.
PICOJAVA_SYSCALL_LIBcontains the name of the dynamic library to be used for the syscall functions. For example:
setenv PICOJAVA_SYSCALL_LIB libsyscall.so.1This environment variable is applicable to both RTL and ias.
IAS_MAX_INSTRUCTIONS: An environment variable that IAS looks up during reset. If IAS reaches an internal maximum instruction limit of 5,000,000 it terminates a program (as a safeguard to halt runaway programs) You can change this maximum by setting theIAS_MAX_INSTRUCTIONSenvironment variable to a numeric value, up to 64 bits. For example:
setenv IAS_MAX_INSTRUCTIONS 23000Sets the limit to 23,000 instructions. setenv IAS_MAX_INSTRUCTIONS 0x23000Sets the limit to 0x23000 instructions. setenv IAS_MAX_INSTRUCTIONS 023Sets the limit to 023 (octal!) instructions. setenv IAS_MAX_INSTRUCTIONS 12345678901234567Sets the limit to 12345678901234567 instructions. setenv IAS_MAX_INSTRUCTIONS -1(or any negative number)Removes the limit.
PJSIM_EXIT_ON_WARNING: If set to any value, causes a memory access warning to halt the simulator. The default is to print the warning and continue execution.
PJSIM_PORT_HANDLER: If set, contains the path to a dynamic library that simulates the serial port, which can be attached to IAS for interfacing a debugger, for example:
PJSIM_PORT_HANDLER libconsole.so.1.
PJSIM_TRACE_LIB: If set, contains the path to a dynamic library which provides functions that are called on every execution of an instruction and on every memory access, for example:
PJSIM_TRACE_LIB sample_libtrace.so.1.
Q. Can I change the values of the machine registers?
Yes, all machine registers are bound to TCL variables. You can set these variables using the TCL syntax and the machine registers are then set accordingly.
Q. What happens if I switch off the stack cache with the scache off
command in IAS?
The stack model specified by the Java virtual machine operates on a stack in memory: the definition of the stack cache, the data cache, and so forth are implementation issues and outside the scope of the Java virtual machine. Hence, the stack cache and the data cache are totally transparent to a program with pure instructions.
When you switch off the stack cache in IAS, it operates as if there was no stack cache and all stack operations were being performed directly on memory. (An analogous condition can never exist on the real hardware since hardware can perform its operations only on the stack cache, which is a register file. Therefore, you cannot switch off the stack cache on the hardware--this is a convenience feature in IAS.)
Q. How accurately does IAS model the picoJava hardware? In particular, how does IAS model dribbling, which is supposed to be asynchronous?
Fairly accurately, since picoJava has a simple microarchitecture without too many asynchronous entities. Modelling stack cache dribbling does pose a problem, however, because dribbling occurs in the background, depending on when the bus is available and other factors. Also, stack cache modelling requires detailed, clock-cycle accurate information. Since this is beyond the scope of IAS, the simulator simplifies things by assuming an infinitely fast memory system, which satisfies all dribble requests before any other requests can go through. For example, if an instruction causes the number of valid stack cache entries to go to 7 and the PSR.LWM is set to 16, IAS instantaneously dribbles in all the entries that are required to make the number of valid s-cache entries equal to 16.
Basically, at the end of each instruction (more precisely, at every update to
OPTOP), the dribbling watermark conditions are satisfied before continuing. The rules on saving and discarding data for overflows and underflows are specified in the caches chapter of the picoJava-II PRM.
Q. Can the contents of the caches in IAS be different from what the contents would be on real hardware?
Yes, they can. Due to the differences between how IAS does dribbling and how it would be done on real hardware, the patterns of memory access in /IAS and in real hardware can be different, leading to divergence in the cache contents. Of course, the state of memory visible from normal programs is consistent between the two.
Q. How accurately does IAS model the FPU inside picojava, esp FP operations involving Nan's whose outputs are not precisely spec'ed by IEEE ?
Completely accurately, down to the last bit pattern. the FPU behaviour for results not completely specified by IEEE is defined in the picoJava-II PRM; ias implements the same. Be sure to compile ias in IEEE-compliant mode on your platform.
Q. Does IAS understand folding?
No, because IAS does not need to understand folding. As far as cosimulation with RTL is concerned, it understands that two or more instructions are folded in RTL and simply issues two
stepcommands to IAS before comparing the state.IAS does look at the
PSR.FLE(folding enabled) bit to decide if hardware level breakpoints are enabled. (Hardware level breakpoints are different from simulator breakpoints.)
Q. How can I extend the simulator?
Any way you want, but the preferred model is to set an environment variable to enable the extensible feature, place the extension code into a dynamic library, and have the IAS core look for this library. You must code into the IAS core the details of when and how to invoke functions in the library that you provide.
Currently, external interfaces exist for the following:
- Calling user-supplied functions after every instruction or every memory reference.
- A system call library, triggered by a memory write to a magic location, which causes the simulator to transfer control to a function in a dynamically linked library.
Q. Can I do limited program I/O?
The preferred way to implement I/O is through the system call mechanism described above. However, if you need very limited functionality, a simple form of program I/O is available through a "console" at address 0x2f0000c0. A
ncstore_byteto this address is interpreted specially by the simulator; the ASCII character represented by the byte is written to the screen.
Q. Can the simulator load ELF files generated by the picoJava C compiler?
Yes. Use the
loadElfcommand, which loads your ELF file into the machine's memory.
Q. What is the picoJava memory map in the current environment? Are there any special locations I can access to trigger special actions?
Yes, some memory addresses have special semantics. For details of the memory map, see the picoJava-II Verification Guide, or see file
$DSVHOME/ldr/src/cm.h.
Q. Can IAS collect instruction counts and other statistics?
IAS collects some information as it runs; however, it does not model clock-cycle-accurate information. See the dumpStats command for details.
Q. Since the picoJava core can be configured for different cache sizes, and for the absence of an FPU, how can I configure these parameters in the simulator?
Use the
configurecommand.