Re: Tonights Tradeoff

On 2024-09-15 3:13 a.m., Robert Finch wrote:

Added support for capabilities to Q+. Most of the instructions are handled by the ALU. Did not want to add a separate capabilities unit to the design. It added about 6k LUTs to the ALU. All the decoding and re- encoding of capabilities chewing up LUTs. They are handled in compressed format. Uncompressed format would require 128-bit registers for 32-bit capabilities. However, it is less logic to use uncompressed formats.
 I am wondering about the phrase ‘if the resulting capability cannot be represented exactly’ in the docs. It seems to me it would be more important that the originating and destination capabilities have exactly the same bounds, base and length. So, I have assumed the phrase to mean that if the capability base and top is not identical to the originating base and top. So, it is checked if the base or top got altered during the calculations. If the originating capability was represented exactly, then the destination one will be too.
 Used a modified version of the compressed format which resolves the capability down to a word address instead of a byte address. This gives a little more range for which the exponent is not needed. I think it does mean that objects smaller than a word in size will not be entirely protected.
 With ECC hardware it may make more sense to use 10-bit bytes for an implementation assuming 10-bits plus 5-check bits. Then there would be a bit available for tagging memory. Been toying with the idea of ECC checked computing. After a higher level of reliability.
 

Moved the capabilities instructions so they are executed on the FPU instead of the ALU. The FPU has 128-bit registers available to it in the form of register pairs specified using the quad-float extension (QFEXT) prefix.