Re: interrupting for overflow and loop termination

John Mashey <old_systems_guy@xxxxxxxxx> wrote:
> David Hopwood wrote:
>> andrewspencers@xxxxxxxxx wrote:
>> > Terje Mathisen wrote:
>
>> A slightly different situation is where you have code that in practice
>> always handles integers that fit in a single word, but that can't be
>> statically guaranteed to do so, and the language specification says that
>> bignum arithmetic must be supported -- the obvious example being Smalltalk.
>> There were some attempts to support this in hardware (e.g. "Smalltalk on
>> a RISC"; also something on SPARC that I can't remember the details of),
>> but it turned out to be easier and faster for implementations of Smalltalk
>> and similar languages to use other tricks that don't require hardware support.
>
> Yes.
> 1) There was Berkeley SOAR as noted, and SPARC included ADD/SUB Tagged,
> which used the high-30 bits as integers, and the low 2 bits as tags; if
> either low 2-bit field were non-zero, it trapped.

And taddcctv (Tagged-ADD-and-set-CC-with-Trap-on-oVerflow)
has been deprecated in SPARC v9,
meaning the opcode will continue to work as specified,
but no performance guarantee (i.e. it may be emulated entirely by software).
V9 specifically suggests replacing taddcctv
with taddcc (non-trap version, essentially just an addcc
with overflow bit from tag portion - hence it's not that expensive to implement)
followed by a branch-on-overflow-set (or by a trap-on-overflow-set).

Of course, having been declared "deprecated" in 1992,
this baggage still has to be carried forward -
it's not possible to reclaim the opcode space taken by these instructions yet.
I don't know if SPARC will ever be able to do so.
Probably not until there's a SPARC v10, if that ever happens.

....
> Anyway, it's pretty clear that relevant mechanisms were being discussed
> ~20 years ago, but nobody seems to have figured out features that
> actually make implementation sense.

Probably because there's no such feature,
beside a fast general purpose user-level trap mechanism you mentioned
in the snipped part of your post.

> I'd be delighted to see a
> well-informed proposal that had sensible hardware/software
> implementations and really helped LISP/Smalltalk/ADA and hopefully
> other languages...

I think LISP/Smalltalk/ADA market is just too small to justify
adding any significant change in the general purpose ISA,
unless this yet-to-be-invented mechanism is easy and cheap
to implement or it is for some other purpose which happened to
help them (like a fast user-level trap).

Having said that, it would be interesting to see any good proposal in this area.
--
#pragma ident "Seongbae Park, compiler, http://blogs.sun.com/seongbae/";
.

Relevant Pages

  • Solaris vs Linux on SPARC and x86/AMD
    ... Is there differences between Solaris 9 and Linux 2.6 in term of: ... hardware vendor support, e.g disk storage ... Is it safe to say that outside SPARC platform, Linux win for all the above? ...
    (comp.os.linux.misc)
  • Solaris vs Linux on SPARC and x86/AMD
    ... Is there differences between Solaris 9 and Linux 2.6 in term of: ... hardware vendor support, e.g disk storage ... Is it safe to say that outside SPARC platform, Linux win for all the above? ...
    (comp.unix.solaris)
  • Solaris vs Linux on SPARC and x86/AMD
    ... Is there differences between Solaris 9 and Linux 2.6 in term of: ... hardware vendor support, e.g disk storage ... Is it safe to say that outside SPARC platform, Linux win for all the above? ...
    (comp.sys.sun.hardware)
  • Re: Solaris vs Linux on SPARC and x86/AMD
    ... > - hardware vendor support, ... > Is it safe to say that outside SPARC platform, Linux win for all the above? ... The primary difference is that Linux has iptables firewall in the ...
    (comp.os.linux.misc)
  • Re: Java Enterprise System for Solaris
    ... |But, remember, you can only use JES products on Sun ... SPARC & x86 systems running hardware from other vendors, ... Working for, but definitely not speaking for, Sun Microsystems, Inc. ...
    (comp.unix.solaris)