;;;-*- Mode:text-*-

BIGNUM File:
	Most of the problem I encountered are in instructions that try to
access memory using a pointer and an offset. Let us suppose that
register a0 has an offset and a1 a pointer. We can distinguish two
cases:

	(1) a0 has a boxed quantity. In this case, we must specify the
byte width of the instruction that adds the pointer and the offset, such
that we preserve the tag field of the pointer. The instruction for a
memory read would then be of the form:

	(alu L+R vma-start-read a0 a1 bw-24 [un]Boxed-vma [un]Boxed-md)

	Notice that the register with the pointer is used as the right
source of the alu. The result takes the top 8 bits from the right
source. Most of the bugs seens in the bignum files are of two folds: the
register containing the pointer is used as the left source, and the
width of the operation is unspecified. Since the width in bits over
which the operation is to be performed is unspecified, the result
contains a bogus tag that is the sum of the tags of the two operands. If
we are lucky we will error because of a transporter trap.

	(2) a0 has an unboxed quantity. In this case, provided that the
tag field of the offset is all zero, it is ok to use a bw-32 width, and
any order in the operands. The instruction can be written as follows:

	(alu L+R vma-start-read a0 a1 [un]Boxed-vma [Un]Boxed-md)

	I suspect that they are still some bugs in the bignum handlers.
Each function should be tested to make sure that bignum routines are
working. I think that I caught all the bugs in the function
BIGNUM-FIELD-PASS, although more testing of the routines will be
appropriate.

K-UC-TV File: