The tagging scheme mentioned above accounts for that. Objects are stored at aligned addresses, which leaves a couple or three bits available for signifying integers and other data types. On architectures that trap on unaligned accesses, you can actually use the trap to avoid an explicit type check if you're expecting a pointer and someone passes an integer.

Almost any implementation masks off the bit(s) before using the value as pointer (when they are not defined as zero for pointers as in this case :)) and stores the objects aligned in memory.

As for performance penalty, unaligned memory accesses are (at least potentially) slower than aligned on almost any architecture. On some architectures they are simple not implemented in hardware and cause an exception (which includes SPARC and essentially anything purporting to be any kind of RISC)

As for SPARC: SPARC actually even has hardware support for similar tagging mechanism: TADDcc and related instructions. Idea is that integers are taged by having two LSB's set to 00. These additional instructions do arithmetic as normal, but also set overflow flag (and optionally cause exception) when any of the operands have tag different from 00. Thus code can do the common case of fixnum arithmetic in one instruction (and possibly OF check) and only when overflow is detected fallback to slower codepath that handles fixnum->bignum overflows and non-fixnum datatypes.

Still totally relevant -- x86 misaligned memory accesses hurt.