LWL/LWR on Input address
BenShen98 opened this issue · comments
I found the behaviours to operating LWL and LWR on ADDR_GETC address have conflict definitions.
From issue #14:
Unaligned: at least one byte of the LWL (or LWR) lies outside the getc address, which is illegal,
and so should result in some sort of address exception.
Aligned: the LWL (or LWR) covers exactly the 32-bits, so would proceed as a normal
aligned read. This forms a really obscure though technically correct case.
And from issue #42:
Loads/stores within [ADDR_GETC,ADDR_GETC+3]/[ADDR_PUTC,ADDR_PUTC+3] trigger I/O (as defined by the memory map).
My interpretation of issue #42 is that it was treating ADDR_GETC as a 'vital' word in memory, with only the least significant byte being non-zero (or all 1 if is EOF), like 0x000000??.
And LWL and LWR will read from memory ADDR_GETC just as read any other physical memory.
On issue #42, it also mentioned:
Still, while this may be incorporated into the spec for future years, I won't do this this year, so other interpretations remain possible as long as they obey the rules listed above.
Does it mean both throw an exception as #14 OR treat ADDR_GETC as normal address by my interpretation for #42 are both acceptable implementation?
I don't think that there is a conflict here. LWL and LWR request four bytes from memory, and the address space of ADDR_GETC is four bytes. If either read is not word-aligned, therefore, there should be a memory exception (per #14) as at least one of the bytes requested will be outside [ADDR_GETC,ADDR_GETC+3].
Per #14, it can be interpreted that LWL at 0x30000001 will throw a memory exception as its LWR pair will try to read an unreadable address. Does this extend to boundaries of other memory areas? Do all of the below throw a memory exception?
LWL 0x30000001
LWL 0x23FFFFFD
LWL 0x10FFFFFD
LWR 0x30000002
LWR 0x20000002
LWR 0x10000002
An LWL should certainly throw a memory exception if it tries to read an unreadable address. But then again, it (and all other instructions) should also throw a memory exception if it causes an unaligned read. So doesn't that make LWL redundant?
As far as the memory is concerned, you seem to have two choices when it comes to LWL implementation. You can either fetch bytes starting from the effective address and discard those on the right of the word boundary, or you can fetch those from the previous word boundary and discard those to the left of the effective address. Which sounds more plausible from a hardware perspective?
The same reasoning applies to LWR.
According to the specification at https://www.cs.cornell.edu/courses/cs3410/2008fa/MIPS_Vol2.pdf we have:
therefore LWL and LWR are valid (should not throw memory exception) in exactly the same boundaries in which LB is valid.
To my best understanding, this:
If either read is not word-aligned, therefore, there should be a memory exception (per #14) as at least one of the bytes requested will be outside [ADDR_GETC,ADDR_GETC+3].
contradicts what we found in the specs.
I am really confused about which one of the two interpretation we should stick with.
I'm trying to guide you to an understanding that (1) what the instruction requests from memory and (2) what the CPU requests from memory are not necessarily the same. Thus,
If either read is not word-aligned, therefore, there should be a memory exception (per #14) as at least one of the bytes requested will be outside [ADDR_GETC,ADDR_GETC+3].
does not contradict the spec, but perhaps could've been more clearly worded since this relates to (2), not (1). Indeed, if non-word-aligned LWLs and LWRs were not allowed in (1), there would be no point to these instructions' existence.
In the current thread, @lhl2617 asked if LWL 0x23FFFFFD should throw expectation, and @jjd06 said yes.
An LWL should certainly throw a memory exception if it tries to read an unreadable address.
But in the previous issue #48, @liqinyang asked if LWL 0x23ffffff be legal or not? And @jjd06 said are legal.
Both of these look like they will access bytes wholly within data memory, in which case they are legal.
So I am really confused, should LWL 0x23FFFFFD or LWL 0x23FFFFFF count as access readable address or not? From my understanding of the current thread, it should be exception and not legal as it would require reading from [0x23FFFFFD,0x24000000] and [0x23FFFFFF,0x24000002] which contain unreadable memory.
In the current thread, @lhl2617 asked if LWL 0x23FFFFFD should throw expectation, and @jjd06 said yes.
No, I didn't. I said
An LWL should certainly throw a memory exception if it tries to read an unreadable address,
which is not the same. The confusion here almost certainly stems from the underlying implementation of LWL (and LWR). So, let me answer your question with a question. You know that LWL accesses four bytes from memory. Which four bytes should it access when called with effective address 0x23FFFFFD?
- 0x23FFFFFD, 0x23FFFFFE, 0x23FFFFFF and 0x24000000
- 0x23FFFFFC, 0x23FFFFFD, 0x23FFFFFE and 0x23FFFFFF
Notice that both of these allow the fetching of the desired data, but (hint) only one can be implemented with a single memory access.
Once this distinction is understood, this issue should (hopefully) go away.
The answer should be 0x23FFFFFC, 0x23FFFFFD, 0x23FFFFFE and 0x23FFFFFF right?
But in such case, why would the unaligned address access LWL 0x30000001 throw an exception?
Shouldn't it access 0x30000000, 0x30000001, 0x30000002 and 0x30000003, which would I assume will not have an exception, as they are all readable?
Exactly. LWL 0x30000001 shouldn't cause a memory exception because it shouldn't issue an unaligned memory read. But if it did (due to an invalid implementation), presumably it should.
I understand the concept now but get more confused about the coursework:
- By spec, should or should not LWL 0x30000001 cause exception? Or is undefined?
- Will unaligned memory read LWL 0x30000001 and similar LWL LWR be tested?
- This is answered above, but, for the sake of absolute clarity, LWL 0x30000001 is a valid instruction that causes a valid memory read, thus it should not cause an exception.
- I will certainly be testing LWL, and may do so with non-word-aligned effective addresses. But the behaviour of LWL 0x30000001, specifically, is not completely captured by the specification in terms of how it should interact with getchar(). Thus, I cannot test it.
Thank you very much.
Now we have a solid understanding of the desired operation based on this spec.
If our testbench tests for LWL/LWR on ADDR_GETC and someone else's simulator fails the test, will our testbench be penalised?
I'm having difficulty understanding the question, but let me make the following statements:
- The testbench testing will quantify the extent to which your testbench can identify non-ISA-conformant behaviour.
- That behaviour will be generated using software under my control. If you are under the impression that I will be running your testbench against other groups' simulators, you shouldn't be.
Do either/both of these help?
Thank you; yes, they help to some extent - I can make my question clearer now.
My testbench expects a certain behaviour of LWL/LWR at ADDR_GETC, when in actuality it is undefined (as per this thread). Therefore it is possible that an ISA-compliant simulator would fail those tests on my testbench. Will my testbench be penalised for failing a simulator on a test where behaviour is undefined?
Ah, I see. Yes, that is problematic. Just as I cannot test for "correct" implementation-defined simulator behaviours, you cannot test for these either. If you do, your testbench may ultimately fail (as indicated by one or more test failures) a simulator that is completely ISA compliant, which would be wrong.
Got it, thank you
We weren’t able to change our testcases due to these late comments, can we request for a short deadline extension to delete some testcases?
I'm afraid not. These comments have not changed the spec.
LWL/LWR - the gift that keeps giving.