```

A student writes:

Dr Patt.

I noticed that the assembler provided does not accept the
full range of values for LDW, STW, and TRAP.  According to
the documentation the offsets are left shifted one bit at
run time.

Absolutely, in order to fully utilize the maximum range, as Satish
and I explained in class when we covered it.

Giving the Trap vector, for example, a range of 0 to 512 even
values.

...actually, 0 to 510 even values.  With 8 bits of trap vector, you
can identify only 256 unique entities.  So, 0 gives you 0, 1 gives you
2, ... 255 gives you 510.  You need 257 values to get 512, and you only
have 256 values in an 8 bit field.

The assembler from the class website doesn't accept anything
bigger than 254.  Is this a problem with the assembler or my
understanding?

Please try it again.  255 works.  We just verified it (to be sure) before

Also I see some ambiguity with signs on hex numbers.
Specifically with AND and x1F.  While that bit pattern
would fit in the immediate value field,
having signs on hex numbers and the lack of a - on that value
implies the intended bit pattern is actually 01 1111 which would not
fit.  How should that be handled?

<<name withheld to protect the ambiguity sufferer>>

Actually, it does not fit into the immediate field if you recall that
the immediate field on ADD, AND, and XOR instructions is taken as a signed
integer.  As you, and the assembly language programmer knows, during the
instruction cycle, the hardware takes that immediate value and SIGN extends
it to 16 bits before using it.  Therefore x1F (+31) does not fit.

It is reasonable to assume that the assembly language programmer knows
how many bits are available in each instruction for the value he/she
wishes to specify.  It is also reasonable for the assembly language
programmer to know how the ISA will interpret the bits of the instruction,
that is, whether the value will be used as a signed value or an unsigned
value, ...and to act accordingly.

Let's look at each case.

1. Immediates as in ADD, AND, XOR, are signed values, as described above.
Thus, from #-16 to #+15, and from x-10 to x+F.  In both cases, the + sign
is assumed if left out.

2. For offsets in LDB, LDW, STB, and STW, the offsets are also signed
values, for the exact same reasons, so the programmer is restricted to
signed values that can fit.

3. For trap vectors, all values are unsigned, so there should be no
ambiguity.

4. For SHF, the shift amount is unsigned, so there should be no ambiguity.

5. For .ORIG, the literal is an address, so no ambiguity.  The preferred
way to express the operand is xWXYZ, where each W,X,Y,and Z are hex digits
corresponding to 4 of the 16 bits of address.

6. For .FILL, the literal value can be either a value or an address.  If
a value, then a signed value.  If an address, then a 16 bit address, like
the case for .ORIG.

I hope that removes the ambiguity.

You will be happy to know that my TAs, in developing the grading scripts,
have enormous compassion and will not test these corner cases.  That is,
if the programmer specifies a value improperly, it will be REALLY improperly!

Okay?

Good luck finishing this on time.

Yale Patt

```