SKI(1)

πŸ“¦ version 1.5.0, in fedora 43, fedora 44

πŸ’– SKI(1) β€” General Commands Manual πŸ’–

okay bestie, buckle up, because we're talking about ski and bskinc β€” the IA-64 Instruction Set Simulator. yes, that's the whole manual name, and yes, it's giving iconic. it lives in the General Commands Manual section, and i'm about to make it make sense. ✨


🌸 NAME 🌸

ski, bskinc β€” an IA-64 Instruction Set Simulator, no cap. πŸ¦‹


✨ SYNOPSIS ✨

so here's the whole vibe of how you call them:

ski [-help] [-i file] [-rest file] [-nonet]     [-srcroot dir]
[-forceuser]  [-forcesystem] [-strace]     [-palen n] [-valen n]
[-ridlen n] [-keylen n] [-grfile n]

bskinc [-help] [-i file] [-rest file] [-noconsole] [-nonet]
[-forceuser] [-forcesystem] [-icnt file] [-strace] [-palen n]
[-valen n] [-ridlen n] [-keylen n] [-grfile n]

like, that's the whole energy right there. notice the two of them are almost the same but not quite β€” ski has -srcroot dir, bskinc has -noconsole and -icnt file. keep your eyes open, bestie. πŸ‘€


πŸ’… DESCRIPTION πŸ’…

so. Ski is an IA-64 instruction set simulator from Hewlett-Packard Company. it simulates the IA-64 architecture exactly as defined by the architecture manual. and before you ask β€” no, it is not a full platform simulator. like, there is no system chipset simulation and no PCI bus simulation happening here. but it does support the full instruction set of the architecture, including privileged instructions and all their associated semantics. so it eats, basically. πŸ”₯

Ski can run in two operating modes: user-mode and system-mode.

in user mode, you run user level applications directly on top of the simulator. the emulation stops at the system call boundary, and then the system call gets emulated by calling the host OS β€” like x86 Linux. Ski handles the conversions between 64-bit and 32-bit parameters as needed. this is what makes user programs execute fast. most system calls are emulated, though ngl, the emulation is not always 100 percent accurate. 😭

in system-mode, operating-system kernel development and execution is possible, because interrupts and virtual memory behaviors are simulated. in this mode you can literally run the Linux kernel, and once it's booted, user applications can be run on top of the simulated kernel. main character energy fr fr. πŸ‘‘

the ski simulator ships with three different interfaces. the simplest one is batch mode, called bskinc β€” a shell running a script.

then there's the full-text curses-based mode, where you can interact with the simulator to inspect code, set breakpoints, etc. that version is called ski.

and the way that all these modes provide the same core simulation, only the interface is different? obsessed. 🫢


πŸŽ€ OPTIONS πŸŽ€

  • -help β€” prints the list of supported options for the specific interface you need. not all options are available in every possible interface, so don't come for me when one's missing. πŸ’€
  • -nonet β€” when you're running in kernel mode, this tells the simulator not to probe for existing Ethernet interfaces on the host. that way the Linux kernel won't detect any device. super useful when you don't want to run the simulator as root (or setuid to root), because for networking support, root privilege is required. πŸ™ˆ
  • -srcroot directory β€” specify the directory where the program sources can be found. this one is only useful when combined with the "mixed mode" display (see the pm command inside Ski).
  • -noconsole β€” do not use an xterm as the default output console; use the current tty instead. only useful when ski is invoked in batch mode, because it lets you run in the current terminal window. this is used mostly within the NUE(1) environment.
  • -forceuser β€” force the simulator into user-mode. normally the simulator auto-detects which mode to run in, but this option exists so you can force user-mode in case the auto-detection fails for some reason. backup plan, bestie. 🩹
  • -forcesystem β€” force the simulator into system-mode. same deal: auto-detection is the default, but this forces system-mode if that detection fails for some reason.
  • -strace β€” displays all the system calls executed by the user level programs. only valid when running in user-mode. the output looks like a highly simplified version of the output from strace(1).
  • -i file β€” process initialization <file> at startup.
  • -icnt β€” store instruction counts in <file>.
  • -rest β€” restore simulation state from <file>.
  • -stats β€” display execution run-time and instruction rate.
  • -palen <n> β€” implemented physical address bits. default: n=63
  • -valen <n> β€” implemented virtual address bits. default: n=61
  • -ridlen <n> β€” implemented RR.rid bits. default: n=24
  • -keylen <n> β€” implemented PKR.key bits. default: n=24
  • -grlen <n> β€” general Register file size. default: n=128

🌈 Running in user-mode 🌈

to run a simple IA-64 program in user-mode only, you just type this:

$ bskinc my_ia64_prg

this will force execution in the current terminal and in batch mode. periodt.

IMPORTANT: to run dynamically linked IA-64 binaries, you need IA-64 versions of the necessary shared libraries installed. on x86 Linux, the easiest way to do this is by installing the NUE(1) environment. don't skip this step, bestie, it will not work otherwise. 😭

🧚 Running in system-mode 🧚

to run a Linux kernel on top of the simulator, you need several components, and i need you to have all of them:

  • a Linux kernel compiled to use the HP-simulator. it needs to have the CONFIG_SIMSERIAL, CONFIG_SIMSCSI, and CONFIG_SIMETH options turned on.
  • a boot loader that goes with it (compiled with make boot in the kernel source tree).
  • a disk image file with IA-64 binaries on it.

please refer to extra documentation to learn in greater detail how to build those 3 components. (yes, three. count them. πŸ’…)

once you have those components, you launch execution by simply typing:

$ ski bootloader vmlinux simscsi=/path/sd simeth=eth0

in this example, the simscsi= option informs the Linux kernel where to find the SCSI disk images. here /path/sd is just the prefix β€” the kernel will automatically look for /path/sd{a,b,c,...}. so the disk image must use the full name, i.e., /path/sda. and simeth= indicates which local interface to use for the simulated Ethernet driver. the simulator must be run with root privilege to get the networking emulation to work. πŸ‘‘

you can specify other options on the command line, just like you would do at the LILO boot prompt for instance.


πŸ“ Getting help inside ski πŸ“

when you run ski in interactive mode via ski, you can get help on commands by typing help. so simple, so iconic.

when running in curses mode, you must make sure you have the PAGER environment variable set to whatever is your preferred pager command. it's usually set to more(1) or less(1). if the variable does not exist, ski will default to using less(1). note that less(1) usually behaves the best when interacting with ski. trust. ✨


πŸ¦‹ ENVIRONMENT VARIABLES πŸ¦‹

  • SKI_USE_FAKE_XTERM β€” if this environment variable is set (the value is unimportant), the ski-fake-xterm(1) utility will be used for output to stdout, instead of xterm(1). this will result in a temporary file created in the current working directory with a name of the form "ski.XXXXXX", where "XXXXXX" can be any six characters.

πŸ’œ SEE ALSO πŸ’œ

qemu(1), bochs(1)


⭐ AUTHORS ⭐

  • Hewlett-Packard Company
  • Stephane Eranian <eranian@hpl.hp.com>
  • David Mosberger <davidm@hpl.hp.com>

and that's the whole page, bestie!! πŸŽ€ written by the lovely folks at Hewlett-Packard Company, filed under Development Tools, in the SKI(1) corner of the manual. go forth and simulate. πŸ’–βœ¨πŸ¦‹

πŸ“¦ where this page comes from