The Secret SX Instructions
pjv
Posts: 1,903
To Ken Gracey;
The SX chips include a number of·unpublished instructions used principally for debugging purposes, however, they are of generic significance, especially for high performance requirements.
On two occasions now I have emailed Ubicom to seek·their clearance to make the SX hidden instructions public by using them in your contest project. I received this privileged information under a non-disclosure agreement, and hence I am unwilling to reveal these wonderful extra SX features without their blessing. They have as yet not responded to me.
Considering the very close relationship Parallax has with Ubicom, could you intervene on behalf of all us SX users, and request for them to permit such disclosure? A public statement by them·in this forum would be a wonderful mechanism to deal with this.
I am certain that once these additional istructions are gererally available, many new SX applications previously difficult or impossible will be realized. I have been using these features for many years now in commercial applications.
It·needs to·be well understood by the users of these hidden instructions that their use can somewhat impair the SX Key debugging process. I have found however,·the additional functionality they bring to FAR outweigh the extra debugging cautions.
I do fear that the use of these instructions, especially with novice users, could create a lot of extra work for Parallax, firstly in additional documentation should you choose to do so, and secondly in questions regarding debugging anomalies.
Hope you can help.
Peter
·
The SX chips include a number of·unpublished instructions used principally for debugging purposes, however, they are of generic significance, especially for high performance requirements.
On two occasions now I have emailed Ubicom to seek·their clearance to make the SX hidden instructions public by using them in your contest project. I received this privileged information under a non-disclosure agreement, and hence I am unwilling to reveal these wonderful extra SX features without their blessing. They have as yet not responded to me.
Considering the very close relationship Parallax has with Ubicom, could you intervene on behalf of all us SX users, and request for them to permit such disclosure? A public statement by them·in this forum would be a wonderful mechanism to deal with this.
I am certain that once these additional istructions are gererally available, many new SX applications previously difficult or impossible will be realized. I have been using these features for many years now in commercial applications.
It·needs to·be well understood by the users of these hidden instructions that their use can somewhat impair the SX Key debugging process. I have found however,·the additional functionality they bring to FAR outweigh the extra debugging cautions.
I do fear that the use of these instructions, especially with novice users, could create a lot of extra work for Parallax, firstly in additional documentation should you choose to do so, and secondly in questions regarding debugging anomalies.
Hope you can help.
Peter
·
Comments
I would be VERY interesting in learning about these instructions. Hint Hint
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com
I don't know about the 8080, but these instructions are to facilitate the real-time debugging process. Fortunately, they can also be well used for generic applications, some with astonishing results. In fact, I have been able to make a real 8 thread·pre-emptive RTOS utilizing some of these instructions. So there is lots of potential to get creative.
I do still wish we could get at the subroutine call stack however.........
Peter
I read your message last night and did not ignore it. I know exactly what instructions you are talking about. I have contacted Ubicom and made the request on your behalf (and that of our other customers, too!). I concur that although the use of these instructions is not earth-shaking in the area of microcontroller programming, it would really make some of our customers happy to have the additional resources. Keeping the cat in the bag is always tough for me as a marketing person with a big mouth, so let's hope for the best from our friends at Ubicom. I admit to being impressed with their ability to make the best decisions lately.
And your ideas about documenting their use are well-taken and appropriate. Until they give us the go-ahead, we're bound by NDAs.
Thanks,
Ken Gracey
Parallax, Inc.
should the day come when you get an ok from Ubicom to disclose information about these secret SX instructions, I promise that I'll try to implement them in SxSim.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I'm just curious if you already have the pertinent data on these instructions. How wide spead might their distribution be, I wonder, and is anyone using them in commercial applications?. Clearly, anyone developing debugging tools would need to be intemately familiar with them.
Peter
·
I swear, I don't know these instructions - I have only heard of them already a while ago, and I know that they are there to allow for debugging. As SxSim simulates debugging, it does not need any special instructions for that purpose. Therefore, I'm pretty sure that I can simulate them, and this is why I made that promise.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
We have approval from Ubicom CFO/CEO to doument the "hidden" instructions. Peter, can you help us in this regard? My preference is that you provide an explanation for them on this discussion forum and I'll trade some hardware or something like that. You can contact me off-line kgracey@parallax.com or call me at Parallax to talk about it 916.624.8333.
Ken Gracey
Parallax, Inc
WOW, you guys are really "jumping to the pump"; this is what I call PERFORMANCE.
Yes, I'd love to be able to be part of the "education" process, and will contact you directly.
This should create quite a bit of novel and creative activity.
Many thanks,
Peter
·
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office
Give me a bit of time, I wish to do a couple more administrative things·and craft my wording carefully·before revealing the goodies. Perhaps this weekend.....
Peter
Sigh. Non-Disclosure Agreements (NDA's) are a pain in the butt. I have no problem with people making profits. I just HATE having doors slammed in my face. "I can't tell you because YOU havn't signed the NDA. Nyaa nyaa nyaa.".
Yeah, I'm over-reacting here. It's really not that bad. I do think it is in Ubicom's interest (and Parallax's, for that matter) to release the information. In fact, since the SX platform is not undergoing new development, I don't understand the value of keeping the information proprietary.
P.S. Just saw Ken's post that Ubicom HAS released the information.· Yay!· Let's jump through whatever hoops remain to satisfy the NDA and release that puppy!
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon Williams
Applications Engineer, Parallax
Dallas Office
-says Paul muffling through his gag, hoping none of his·IT's are in earshot.
Post Edited (Paul Baker) : 12/10/2004 8:29:09 PM GMT
I have the approval of their CEO/CFO to permit Peter to explain these instructions. But just to be sure I am asking them to void the NDA which Peter signed so he can freely document their uses. We have a good relationship with Ubicom and this won't pose a problem for him or anybody else. Sit tight and I'll get Peter his legal clearance (from them) so he can rest assured he's safe.
Ken
I now have offical approval from Ubicom that your NDA is null and void, so you are free to write about these instructions. I will forward it to your personal e-mail. Hopefully everybody's hopes are not unreasonable at this point, because this isn't a major breakthrough but more of a convenience for seasoned SX programmers.
Ken Gracey
Well, I have just now received clearance from Ubicom to reveal the hidden instructions, so I will draft a post here·over the weekend to explain what I know about them.
As Ken has already cautioned, don't expect these to be too earth-shaking, but more as a·useful extension to the standard instructions, especially for "power-users". As a·further caution, some of these instructions will exhibit results in the SX that may be not too readily grasped by novice users, so my recommendation is to not use them unless you know what you are doing. USE THEM AT YOUR OWN RISK as "YOUR RESULTS MAY VARY".
Again I need to caution those who plan to use these instructions that under certain circumstances, mostly to be discovered by yourselves, these instructions will adversely affect the correct performance of the SXKey debugging tool, and perhaps other's tools as well, altough I have no experience with such others.
I wish to thank the folks at Parallax, and in particular Ken Gracey, for assisting me in getting the release from Ubicom·and making·this distribution possible.
Peter
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Chris Savage
Knight Designs
324 West Main Street
P.O. Box 97
Montour Falls, NY 14865
(607) 535-6777
Business Page:·· http://www.knightdesigns.com
Personal Page:··· http://www.lightlink.com/dream/chris
Designs Page:··· http://www.lightlink.com/dream/designs
·
So here we are, ready to "spill the beans", but first, some legal stuff.
The information I am disclosing and posting here is my personal experience with these "hidden" instructions, and is in no way deemed to be totally correct or complete. Inasmuch as I had no hand in the creation of these instructions, I am only disclosing how I believe them to function. I have not exhaustively tested the performance or results. I have however successfully used them in many applications with excellent results,·but any user of them is advised to test the performance for their own application, and use them at their own risk.
The performance of the SX Key debugging tool, and the content of the debugging windows may be affected by the use of these instructions, so user beware; what you see may NOT be what you get.
About the SX interrupt.
The SX family has a wonderful interrupt facility which stores the state of the processor system registers, that is the content of W, STATUS, FSR, PC, (and in the SX48/52 also M) registers at the instant of interrupt. It "pushes" them onto shadow register stacks, one associated for each of these system registers. In fact, the shadow registers each are a non-circular stack, two levels deep.
When interrupt is exited through the RETI or RETIW instruction, each of the shadow stacks is "popped", and the original system register's states are restored to the point just prior to interrupt. So interruption and restoration is handled in hardware.
The hidden instructions.
One group of the hidden instructions can modify the content of these shadow stacks, and another group can read the contents of the shadow stacks. Specifically:
"pushW" ($048) will push the content of W onto the Wstack;
"pushSTAT" ($049) will push the content of W onto the STATstack;
"pushFSR" ($04A) will push the content of W onto the FSRstack;
"pushPC" ($04B) will push the content of M(4bits) and W(8bits) onto the PCstack.
Conversely,
"popW" ($04C) will pop the upper level of Wstack into W;
"popSTAT" ($04D) will pop the upper level of STATstack into W;
"popFSR" ($04E) will pop the upper level of FSRstack into W;
"popPC" ($04F) will pop the upper level of PCstack into M(4bits) and W(8bits).
Executing any of these instructions, I believe,·does not affect the STATUS flags.
As these shadow stacks are two levels deep, two consecutive "pushes" or "pops" will affect the second level of the stack, of course through the first level. That is, the first push transfers the first level to the second level, and W to the first level. Similarly, the first pop will bring the first level into W, and the second level into the first level, and the second pop will bring the now first level (this had been the second level) into W. I do not recall for sure, but I believe pops enter zero into the second level in which case two consecutive pops would clear the stack.
There is an instruction called FIFO ($047) which pushes W onto an 8 level circular stack, and rolls the content of the eighth level into W. This is used during debugging to save some data which later needs to be restored, all without the use of the processor's normal "RAM". So executing FIFO 9 times, circulates W through the circular buffer once. There is no "reverse"; FIFO only moves in a "forward" direction, albeit in a circular fashion.
There are some other instructions which are probably less interesting to most users, as they are principally used only in the debugging process so I will only mention them here, and not go into detail as I have not used them.
$001·moves the option register to W
$044·sets the SX into debug mode
$045·shifts the oscillator pin into/outof W
$046·sets the breakpoint register
So What's the big deal?
Well, of the push/pop/fifo group, firstly one can "pushW" to temporarily store, and later retrieve·W without using a RAM location. Very useful for passing·a parameter (or·two·"pushw"s·for two parameters) to a subroutine where it is "popped" into W. If a real interrupt occurs in the case·when two·"pushW"s have been issued, the first one will be lost as·the interrupt·will push it·out of the stack. Single "pushes" are safe during an interrupt, but then the debug process may compromise the pushed contents.
But there is more. One can, while NOT in interrupt, load up the top level of each of the shadow registers for W, STATUS, FSR, PC and then do an RETI or RETW, and voila, start executing another thread with its restored values. Naturally one would need to save the context of the processor prior to activating this other thread.
This is one method I use to have the RTCC interrupt give me a tick every xx microseconds, and I run all other threads timed from that tick by sequentially picking up previously suspended threads of higher priority, and restoring their contexts. This works really well, depending on how creative you want to be. The result is a pretty good performance pre-emptive RTOS for the SX.
So that's about it, experiment to your heart's content, and you'll probably find out things I haven't discovered yet.
Thanks again to Ubicom for permitting this disclosure, and to Parallax for their help.
Above all, have fun,
Peter
thank you for this very interesting and helpful information.
As promised, did I implement these secret instructions in SxSim, and I have posted a new version SxSim 1.50 - you can find it attached to the top message in the SxSim-related "sticky" thread.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
I am somewhat curious how these instructions can be simulated when all of thier repercussions are not known in advance, though I suspect thier simulated behavior can be tweeked after people experiment with them abit (Im refering mainly to the instructions disclosed but undocumented by Peter, namely the debug mode (does it just enable/disable the breakpoint? Perhaps Ken can provide more info)).
I think its worthy to note that if you are using the internal oscillator, the $044 (swap osc pin with w) can be used to gain an additional I/O pin.
I think the most useful instruction of the lot is the FIFO instruction, this could be used by a wide variety of communications protocols to buffer data without consuming valuble RAM (it could also be used for a "slow ram" as well).
I am assuming that SASM does not provide direct support for these instructions, so to implement the FIFO instruction one would write "dw $047" within the program body?
Anyone feeling adventurous enough to look at the instruction map and inserting undocumented codes in a program in an attempt to sniff out other undocumented instructions? I'd try this, but I do not have the appropriate diagnostic tools to observe real time behavior of the chip. With enough effort perhaps what I consider the holy grail (access to the call stack) can be uncovered, if this is discovered using this method the information is not under an NDA since none of the info was garnered through Ubicom. It appears that Ubicom chose $04X to implement all but one of these instructions, a good place to start seems $040-$043. Though some or all of these maybe·documented instructions.
Paul
Post Edited (Paul Baker) : 12/11/2004 10:03:02 PM GMT
due to the Harward architecture of the SXes, program code and data are two differnt sides of the same coin. Therefore it is only logical that the call stack can (and should) only be used for storage and retrieval of program addresses, and not for passing parameters as "we C programmers" are used to.
Nevertheless, the secret FIFO instruction and the various PUSH/POP instructions offer interesting alternatives, although PUSH/POPs are somewhat limited to applications w/o interrupts as they make use of the same "shadow stacks" for saving the register contents.
In my book, I describe the implementation of an "FSR stack". Although this approach "eats up" some of the regular RAM space, it can easily modified to be used as a "W-Stack", allowing to pass several parameters to functions.
As I had mentioned in another thread, it is quite easy to implement a set of SASM macros that allow you to use "mnemonics" instead of DWs, like
FIFO macro
dw $047
endm
As SASM allows for include files, you could put all of them in one include file.
It just hit me...
Peter M.: It would be a nice feature if the SX-Key IDE had an option where "default include files" could be specified, like one containing macros for the "secret" instructions. Besides this, you also might consider to introduce some new mnemonics in SASM for the no more "secret" instructions
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
A long time ago, after I received access to these additional instructions, I made up a big spread sheet and went through all the combinations possible with the 12 bits. To the best of my recollection there are no further "holes" hiding something.
I have repeatedly asked about other "hidden" capabilities, and, like yourself, was desperately looking for access to the subroutine call stack. Unfortunately the answer back from Ubicom was a consistent no-go.
I did learn however that there was some additional capability, (perhaps through the flash progamming access model ?) for testing or exercising the chip, ·but was unable to get any detail at all. Probably it is indeed best for us to keep our noses out of that area.
I'm glad you like the FIFO, but for me the very BIG WIN is the RETI instruction after I alter the shadow stacks.
Hope you, and all others of course,·can make good use of these new-found features.
Peter
Your description of the extended instructions encapsulated in macros is exactly what I have been using for years now. Also, it works with the SX/B compiler, but as I·recall, it needs to be wrapped in an ASM/ENDASM command.
About·your suggestion of passing parameter(s) in the Wstack, please remember that an interrupt will use one stack level, and the debugger will also use one stack level (hence the two level stack), leaving none for parameter(s) unless these two events are assured NOT to occur. The interrupt does not use the FIFO.
Peter
I want access to the call stack to implement indirect threaded coding, though re-reading Peter's disclosure I think it can be done via his task switching method, its just not as elegant as using the actual call stack.
Peter,
I understand, it was worth asking. Those additional features they won't share are likely metric performance routines that are used to test each chip before certifying them and sending them out the door, so its not very likely that they are of any real use to a programmer, hence thier stone-walling. I now agree with you that the reti trick is a big winfall as it seems to provide a roundabout method for accomplishing what I wanted from access to the call stack to begin with.
Paul
PS Thanks for reminding me about the use of macros, many of my programs are somewhat space confined so I usually have to resort to function calls to minimize space.
I vote that this thread eventually be made sticky, is there anyway once that is done to either extract Peter's disclosure or lop off all preceding posts (I say this to make the pertinent information readily available and·mean no disrespect·towards the preceding posters)
Post Edited (Paul Baker) : 12/11/2004 11:56:44 PM GMT
"Move option to W" is interesting... why would they want to do that? So that the debug code in the SX can understand what context it is running in? Hummm... I don't see a need for that right off the bat...
"Set debug mode" is VERY interesting. What exactly does that mean? Could one think of that as basically a secondary software interrupt? If I'm willing to loose the debugger, can I use that to implement other functions that I can get to with only a single word of program space? e.g.
int2 macro ;lets pretend that it is actually a second, software only, interrupt·vector.
··· DW $044 ;although it is really just the "set debug mode" secret instruction.
··· endm
callx macro 1 ;not your regular call...
··· int2 ;trigger the special new "microcode"
··· DW \1 ;and record a target address after that one
··· endm
· org regularCode
· callx somewhere
· ;etc...
· org debugcode ;callx causes·us to·show up here with shadow registers loaded
· popPC· ;where did we come from?
· inc Wreg· ;we will go back·a word later
· pushPC· ;and dont you forget it
· dec Wreg· ;...and yes you can inc/dec W if you have·the right options set
· IRead··;what was the next thing at that location?
··jz return·;if it was zero...·but more on that later
· pushPC ;'guess that kills the·regular interrupts 'cause we·would loose our return PC
· reti ;this takes us to the target address of the callx
retx macro ;but what if there was no target address?
· int2
· DW 0 ;since we will never call address 0, this must be a flag of some kind....
· endm
return ;ah! The address after the int2 was a flag that we actually need to return...
· popPC ;ok, we didn't want to go back there after all, so forget it
· reti ;and return back to the original PC that we didn't forget
· ;WITH all the registers intact from the subroutine
somewhere ;now we are getting...
· ;do some stuff.. W,·Status,·and FSR are all still intact from the callx
· ;change the registers as we will and...
· retx
·
"rotating the osc pin through W is now the Key talks ot the debug code in the SX, no questions there. But isn't there a way for the SX-Key to break into the debug code? Is there a sequence that initiates debug when you put it on the OSC pin? Can that be used to implement a third sort of hardware interrupt? (B register, external RTCC, and now OSC interrupts)
"set the breakpoint register" is a real hum dinger. I assume that it loads M and W in to a shadow register and when the PC hits that address, an "interrupt" to the debug routine is initiated? So I can have multiple breakpoints in my code IF I set them up in the code itself?
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
Can that implement a better call? Well, no I guess not because you only have a 2 level return stack and really only one level if you want other interrupts and 0 levels if you want interrupts and debug. But you could use it to do a better jmp PC+W or a jump to any location pointed to by a pair of file registers...
In the main code you would just load two file registers with the exact location you want to jump to and then trigger the "software" interrupt. The ISR then does a:
· popPC
· mov M, fr1
· mov W, fr2
· pushPC
· reti
And that could make a very nice sofware return stack if you used FSR instead to point to the file registers with the address to goto.
· popPC
· mov M, ind
··inc FSR
· mov W, ind
· inc FSR
· pushPC
· reti
To do a call, you would need to use another B pin, and in the ISR do:
· popPC ;where did we come from?
· inc Wreg ;we will go back a word later
· mov ind, W ;and we will remember where to go on the "stack"
· dec FSR ;which uses FSR as the stack pointer
· mov ind, M ;and two file registers per stack location
· dec FSR ;good thing I don't have to check for overflow or anything here isn't it ;>
· dec Wreg ;...and yes you can inc/dec W if you have the right options set
· IRead ;what was the next thing at that location?
· pushPC ;'cause that is where we are bound
· reti ;high low floater! And away! (or you can or if you like, xor even, I don't care)
Hey that looks pretty cool! What did I miss? Quick, somebody shoot it down before I get a big head! <GRIN> Oops, I mean
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
Post Edited (James Newton) : 12/13/2004 7:29:53 AM GMT
How cool is it to actually have a real fifo in the SX? Now we can have buffered IO without anywhere near the software overhead...
This is 8 x 8 bits of storage so I can shift in serial data from a port pin at pin 0 or 7 in a two instructions per bit unrolled loop for 8 bits·and then fifo each byte in one instruction for a 256 bit serial capture at 25Mhz. Err, no, cause I still have to FIFO, get a bit and save a bit for each byte, so it would be a bit less than 25Mhz. Or I could use RA as a 4 bit shift register; sort of the opposite of this:
http://www.sxlist.com/techref/ubicom/lib/io/dev/video/chgenra-jmn.htm
· rl ra ;xxxa
· nop
:loop
· rl ra ;xxab
· nop
··rl ra ;xabc
··mov ind,·W
· mov w, <>ra ;abcd 0000
· inc fsr
· rl ra ;xxxe
· setb fsr.4
· rl ra ;xxef
· nop
· rl ra ;xefg
· nop
· or W, ra ;abcd efgh
· dec count
· rl ra ;xxxa
· jmp :loop
Agh! Darn it, it turns out there are so many free cycles in that code that we might as well just use FSR and the file registers to save the data.
That FIFO is still great for giving us an extra 8 bytes of RAM but it doesn't seem that good for speed related stuff.... Well I can do 8 byte wide captures at 25Mhz...
· mov w, RC
· FIFO
· ;do this 8 times
and I guess you could add two pushW 's to the end, and don't forget W itself·for·a total of 11 bytes captured at 25Mhz. Hang on though, I can just do:
· mov w, RC
· mov 8, W
· mov w, RC
· mov 9, W
· mov w, RC
· mov 10, W
· mov w, RC
· mov 11, W
· mov w, RC
· mov 12, W
; etc...
and on through every available file register as well. So without pausing for bank select, we can capture 19 bytes at 25Mhz.
To bad I can't do FIFO RC
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
---
James Newton, Host of SXList.com
james@sxlist.com 1-619-652-0593 fax:1-208-279-8767
SX FAQ / Code / Tutorials / Documentation:
http://www.sxlist.com Pick faster!
My, you·HAVE been very busy looking at novel applications for these extended instructions.
Your supposition that a port B pin could be used as a software triggered interrupt is something I tried a long time ago, and to the best of my recollection, did exactly what you descibe. It is indeed a great way with a single action to capture the current state of the processor......provided it's not already in an interrupt.
Many of my applications use precise DAC voltages generated by the "overflow" method (I don't know the official name for this algorithm) to generate control or offset voltages, and hence, depending on the degree of precision required, need to have the DAC·addition calculation executed at EXACTLY the same instant every cycle. As a result, I can't afford to have one non-realtime (software) interrupt mess up the RTCC interrupt, so I have not used this state capture method. During debug, the jitter in the SX-Key PLL was sufficient to disturb the stability of the readings, and I implemented a modification to the SX-Key oscillator to put on a fixed crystal can at 50 Mhz. Now·in debug, the·RTCC·interrupt is truly "rock"-solid.
In my RTOS I just have to do it the old fashioned way, which unfortunately does consume some cycles, but lets the RTCC genserated ISR run on EXACT timing.
In fact, by being careful with this timing (as well as other things), I have been able to implement a 14 bit software charge-balanced AtoD with just two resistors and one capacitor. I find it rewarding to squeeze so much performance out of so little hardware.
Have fun exploring,
Peter
·
yes, I'm aware of that - when interrupts may occur, it is only save to use one level of the "mini shadow stacks"
BTW, I have made another change to SxSim. Former versions reported an error when a RETI or RETIW was executed w/o a prior interrupt. Now, that these instructions can be "mis-used" to retrieve data from the "mini shadow stacks", this error message might be not in order. Therefore, I have added an option to disable this check.
I'm going to post the new version (1.51) plus the updated docs in a minute.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G