Re: [Tack-devel] INN / SET EM instruction behavior on ignored trap

[Carl E. C. <cec...@ya...>]

 Greetings,               Actually the current behavior seems already OK, if the bit number is outside the allowed range, ESET is thrown, the only problem where I had some doubts:
* If the trap is ignored completely (on platforms that do not support it, or through the SIM instruction)

In that case, what should be the value returned? But you just gave me the answer by looking at the old pascal interpreter code (which I forgot to look at), the value 0 is pushed back on the stack, which what i thought also to do, so its consistent.

p.s: I am writing a complete instruction reference manual that should describe each instruction with the possible traps that can be thrown, but it is far from finished.

Carl


    On Saturday, June 22, 2019, 7:34:29 a.m. GMT+8, David Given <dg...@co...> wrote:  
 
 
The EM spec PDF (see the white papers section on http://tack.sf.net) has a sample interpreter written in Pascal in one of the appendices, and INN is implemented as:
begin  k:=argw(k);
  t:=pop;
  i:= t mod 8;  t:= t div 8;
  if t>=k then
    begin trap(ESET); s:=0 end
  else
    begin s:=memb(sp+t) end;
  newsp(sp+k);  push(bit(i,s));
end;

So it does raise ESET if the bit's out of bounds. But that doesn't seem to be actually specified anywhere, and ESET itself is not referred to anywhere in the spec other than as 'set out of bounds error'.
I don't think specifying that it raises an error would be a good idea, as that cripples good code generation for, e.g., word-wide sets (where it can just turn into a shift left of 1). Your suggested behaviour is sensible but it doesn't allow for ESET to be raised on platforms which do support it --- I see that several libem libraries do it. So I'm wondering whether we should define it as (a) undefined, (b) either raising ESET or the behaviour you describe, (c) your behaviour and then remove the checks from the existing code (or just leave them in and declare them as non-comformant...).
On Fri, 21 Jun 2019 at 18:35, Carl Eric Codere via Tack-devel <tac...@li...> wrote:

Greetings,               The EM interpreter, which I am using as reference for the EM testsuite does not define the behavior of the INN and SET instructions when the bitno is outside of the allowed range and the ESET trap is ignored.
I propose the following for SET: Create the set but not set any bit, since the bit number is invalid.I propose the following for INN: Always push a value of zero indicating that the bit is not in the set, thus avoiding reading illegal memory.
Comments welcome...If ok, i will update the code accordingly...
Carl




_______________________________________________
Tack-devel mailing list
Tac...@li...
https://lists.sourceforge.net/lists/listinfo/tack-devel



-- 
┌─── http://www.cowlark.com ───
│ "I have always wished for my computer to be as easy to use as my
│ telephone; my wish has come true because I can no longer figure out
│ how to use my telephone." --- Bjarne Stroustrup