[movitz-devel] Re: Question about :sub-program

[Frode Vatvedt Fjeld]

james at unlambda.com (James A. Crippen) writes:

> I have a minor question about assembler syntax. What's the
> :sub-program frobnitz supposed to be doing here?

The argument syntax is something like this:

   (quote (:sub-program (&optional (label (gensym))) &rest sub-program))

and this will insert the label and sub-program somewhere below that
instruction in the program. That somewhere will have to be
after e.g. a jmp or ret instruction. After the assembly reader is
done, that argument is going to look the same as (quote <label>) to
the instruction whose argument it was. I mean..
(:je '(:sub-program (foo) ..) is just the same as (:je 'foo), except
there's the side-effect that the label foo and the sub-program will be
inserted below.

>    (:jnz '(:sub-program () (:int 66)))

So this is just a convenient way to say "unless the zero-flag is set,
signal exception 66". This assumes that the exception-handler for 66
won't return normally, since there's nothing specified if it does.

> Sometimes I see it with an argument:
>
>    (:jl '(:sub-program (failed)
>           (:int 112)
>           (:halt)
>           (:jmp 'failed)))

So this will end up something like this:

  (:jl 'failed)
  ..whatever..
  (:ret)
 failed
  (:int 112)
  (:halt)
  (:jmp 'failed)

This looks like someone didn't intend for the handler for exception
112 to ever return normally, but still wanted to take some extra
precaution in case it did return after all.

About exceptions in general, I haven't really been very disciplined in
using them. I've used the "think of a number that hopefully isn't
already used" strategy and mostly forgotten about actually dealing
properly with the exceptional situation. 112 for example, I believe I
used for when running out of memory in the older allocation scheme. In
the GC architecture in losp/los0-gc.lisp you'll see I use 113 instead,
and here in a rather self-contained manner (i.e. the number 113 isn't
spread out in code all over). Of course, the proper thing is to have
some mechanism for allocating an exception number for such cases.

So there would be four ranges of exceptions: the hardware exceptions
(division by zero etc., 0-32), the interrupt exceptions (currently
32-48), then the "Movitz" exceptions that the compiler and run-time
knows about (tentatively 50-128) and application-specifics (128-255).

Not what you asked, I know, but I get carried away :-)

-- 
Frode Vatvedt Fjeld