-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Math Lib in Monitor: Add SHL32 and SHR32 #160
Comments
Let us brainstorm a moment:
That does not work for shifts of >= 16 bit positions but might be a conversation starter. It could also be complete balderdash... ;-) Good night. :-) |
As my approach would be the inelegant and slow loop, I am truly impressed by this idea, though I do not understand how it works. I could perfectly live with not being able to shift more than 16 bit positions at a time, because we could put this algorithm in a loop to make arbitrary bit positions > 16 possible 😈 @MJoergen, thoughts? |
I like @bernd-ulmann 's idea very much. Actually, I have seen a similar algorithm used in VHDL :-) I expect to implement it later today or tomorrow. |
I've implemented both routines now. The only problem is that I've (so far) changed the semantics of If any of you see a way to preserve/manipulate the X flag in the shr32 routine then please go ahead. |
Ah, my last comment was not entirely correct. The real problem is that the RET instruction itself modifies the X flag (and N and Z), because it really is just a MOVE instruction in disguise. So the only flags not modified by RET are C and V. We could consider introducing a special RET instruction that does not modify any flags at all, much like we did with INCRB and DECRB ? |
One more thing: I just realized the C library has 32-bit shifts built-in. Look in e.g. |
Hmmmm... Just a quick question - did we ever use the X-flag in any context except shift instructions? The reason for asking is that I (personally) would prefer changing the behaviour of X slightly instead of introducing a "real" RET instruction. Let us brainstorm for a moment... :-) |
@bernd-ulmann : I'm not sure what you mean by "changing the behaviour of X slightly". |
Me neither... :-) That's what we might brainstorm about. We could eg. say that X is no longer implicitly set by any instruction other than shift instructions. The only way to set/reset it otherwise would be an OR/AND with SR. Just a possibility and maybe a stupid idea but if we never used the X bit until now we might very well think along this line, what do you think? |
I don't know if the X bit has been used in other programs already. @sy2002 should be the one to answer that. It is an "unusual" status flag (indicating a value = -1), meaning I have not seen anything like it in other systems/processors. Yes, we do need to brainstorm on this! |
I never understood the use-case of the X flag outside Therefore, here is my suggestion (which is basically just based on what Michael and Bernd already wrote above):
Please indicate with "Thumbs Up", if you want to proceed like that, because then we do not need a call :-) So this issue could be completed and closed as soon as Michael finished the SHL32 and SHR32 functions and wrote a test program in @MJoergen Regarding your comment #160 (comment) about the SHR32/SHL32 implementation in the VBCC library: As soon as your monitor functions SHL32 and SHR32 are ready and tested: Wouldn't it make a ton of sense and replace the slow C code implementation in |
I just changed the emulator so that the X-bit is only read/changed by shift instructions and adapted the documentation accordingly. (In case we decide against this path we can just roll back these small changes. :-) ) |
I would instead suggest a different solution, which is to keep everything as it is, except for one small change:
All the other instructions should keep their existing behaviour. The reason is that somehow I think it is useful to be able to test e.g. whether an OR instruction gives a result 0xFFFF. In other words, I would like to keep the possibility of writing:
This is not super important to me, but more a nice-to-have. @sy2002 : You wrote
I'm not sure what is missing? The latest version on the Regarding the C library, I've opened a new Issue #164 . |
@MJoergen About your X flag behavior sugestion: I like it - but Bernd as our master of the ISA should decide. @MJoergen Sorry, I did not see your latest commit today, when I wrote that. Thank you for being so fast: This will allow me to continue with I am opening a new issue for the architectural change of the X flag. |
@MJoergen reopened this one due to this result in most recent emulator:
|
Dear Michael - to decide about the behaviour of the X-flag is not easy. I though about it for the last about 2 hours. I, personally, would opt to have the X bit only modified by explicit AND/OR with SR or due to a shift instruction. I can fully understand your desire to have this flag modified by all other "normal" instructions except MOVE but to be honest, it does not feel right. It would a rather arbitrary special behaviour which applies only to MOVE. Having no instruction implicitly modify X except SHL and SHR is "cleaner" and I think, I could sleep better if we could decide to go down that route. Did we ever use the X bit at all in our existing code? If not, then there was (at least until now) no real reason for any instruction (except SHx) to implicitly modify it, what do you think? |
Ok. I don't have strong feelings either way, so I support @bernd-ulmann's suggestion. |
There was a bug in the latest emulator, where the X flag was cleared after every instruction. That was why the Closing again :-) |
@MJoergen I did a retest of |
@MJoergen As written in #160 (comment) I did run your test program in the emu and it worked. Will work with it at the week-end on hardware, too. Question about the semantics: Is it fair to assume, that SHR32 fills with C and shifts to X? So same semantics as SHR? If yes, then I did it right (please double check my commit): I updated the documentation in |
@MJoergen Stumbled over a piece of documentation that potentially needs update and therefore reopened this issue and assigned to you: Please check, if your SHL32/SHR32 are safe to be used inside ISRs (as by far not all SYSCALLs are safe) and update the list of safe math routines here, if they are: Having had a quick look at your code, I would assume: Yes, they are. But please you decide. Then close this issue again. |
If one of the Math PhDs @bernd-ulmann and @MJoergen would like to do me a favor, then you could implement these
SHL32
andSHR32
stubs inmonitor/math_library.asm
(and maybe even add a test program for it to thetest_programs
folder). I already added the SYSCALLs to the jump table inmonitor/qmon.asm
.I probably will need these functions next "nerd Saturday" for "tile_ed" - so in case you did not do it until then, then I will do it.
The text was updated successfully, but these errors were encountered: