Module object 

Typed calculator objects (the JSON model of saturnus’s tools) and the exact decoder for objects in the calculator’s nibble format, whether from a binary transfer or read straight from memory.

Body layouts: wiki: protocols/hp-object-format (“Object bodies”), from RPLMAN chapter 3 and objects observed on the 48SX and 49G.

• Reals keep their exact 12-digit mantissa (Real); JSON shows them as numbers (12 significant digits survive an f64) unless the exponent is beyond an f64’s range, then as text such as "1.5E-400".
• Built-in constants inside composites are 5-nibble ROM pointers; a Memory reads the object they point to (the emulator’s ROM). A pointer to a command (a program, code or a primitive in ROM) is not followed: it becomes Object::Command with its address, and with its name when the reader has the ROM’s NameTable.
• With a NameTable, programs, algebraics and unit expressions get the calculator’s text (crate::decompile); without one their source stays unset and a host may fill it from the calculator’s own text (an ASCII transfer: crate::transfer::fill_sources).

Structs

Graphic

A GROB’s picture: width by height pixels, rows the pixels packed one bit each as hex digits (two per byte), every row starting on a byte, the leftmost pixel in the most significant bit, 1 dark: the page’s frame layout, so a picture is drawn like the screen.

Integer

A 49G exact integer: sign and decimal digits, any length.

NoMemory

No memory: ROM pointers stay Object::Command.

Reader

Decodes several objects in memory (the levels of a stack) under one budget of MAX_DECODED_OBJECTS and MAX_DECODED_NIBBLES: the caller gets one bounded result, however many levels point at the same large object.

Real

A real number exactly as the calculator stores it: sign, 12 decimal digits with the point after the first, exponent -499..=499.

Enums

ArrayItem

One array element or a row of them.

Base

The display base of binary integers (flags -11 and -12).

Object

A calculator object as the semantic tools return and accept it.

Constants

MAX_CLONED_NIBBLES

Most nibbles one decode may hand out again for pointers that repeat an object already read: DUP copies the pointer, not the object, so a real stack can hold one large object at many levels, and each level is a copy in the result. 16 M nibbles (8 MB of object data) covers forty copies of a 400 K-nibble GROB; past it a crafted stack of thousands of pointers to one large object is refused instead of producing gigabytes.

MAX_DECODED_NIBBLES

Most nibbles one decode may read from memory, each object once: four times the 49G’s whole RAM (512 K nibbles), so nothing a calculator holds is refused.

MAX_DECODED_OBJECTS

Most objects one decode may produce. ROM pointers can share a target, so without a bound a few hundred nibbles of crafted or corrupt memory (lists of two pointers to the next such list) expand to 2^64 objects. The largest object a calculator holds is under 512 K nibbles (the 49G’s 256 KB of RAM; a 48GX card port holds at most 128 KB), so it has at most about 105 000 elements (5-nibble ROM pointers, the smallest); 2^18 is two and a half times that. The work to reach the bound grows with it (every object is built before the next is charged): 2^18 keeps a refused decode near 50 ms in a debug build.

Traits

Memory

Read access to the calculator’s memory, for ROM pointers.

Functions

decode

Decode the object at the start of nibbles. An object the walk does not understand becomes Object::Unknown with all of nibbles.

decode_at

Decode the object at addr in mem (a stack level, a variable): an object with a known prolog, else a primitive or ROM word (Object::Command with its address).

graphic

The picture of the GROB n (all its nibbles, prolog first), or None when it is not a GROB, has no pixels (0 wide or high, as #0 #0 BLANK makes), is too large, or its fields do not add up. The layout (wiki: protocols/hp-object-format, “GROB layout”): prolog #02B1E, length, height, width (5 nibbles each, low nibble first), then the rows, each padded to a whole number of bytes; within a nibble the least significant bit is the leftmost pixel.