1. Forum
  2. USENET
  3. comp.arch

  • Re: interrupt handling latency and weird register use (was Re: OT: Epic RISC-V rant)

    From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.arch on Thu Sep 3 02:56:00 2026
    From Newsgroup: comp.arch

    On Tue, 01 Sep 2026 17:00:23 -0300, Kragen Javier Sitaker wrote:

    Hardware multiplication is crucial for all kinds of applications,
    including software-defined radio and other DSP, image processing,
    3-D rendering, and neural networks. By contrast, hardware division
    is a minor advantage but rarely appears in inner loops, and has been
    omitted from historical architectures including the Cray-1, Cray-2,
    and ARM.

    As I recall, early versions of Sun SPARC omitted integer hardware
    multiply and divide, on the grounds that such instructions occurred infrequently in the traces the designers collected while running
    various example programs. They changed their minds later.

    Seymour Cray omitted floating-point divide in favour of multiplication
    by the reciprocal. He did include a reciprocal-approximation
    instruction that would give a full-accuracy result after two
    iterations.

    However, I think there are rounding issues with trying to make
    floating-point multiplication-by-reciprocal stand in for division in
    general. Which is why nobody follows CrayrCOs example these days.
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From Lawrence =?iso-8859-13?q?D=FFOliveiro?=@ldo@nz.invalid to comp.arch on Thu Sep 3 02:59:28 2026
    From Newsgroup: comp.arch

    On Wed, 02 Sep 2026 08:11:15 -0700, Andy Valencia wrote:

    This brings back memories of MIPS' K0 and K1 registers. From
    non-interrupt code perspective their value could change
    asynchronously, as they were there to be scratched upon by the
    lowest level of interrupt and trap entry. It always struck me as a
    covert channel, though I never came up with a way to use it.

    People were so much more na|>ve back then ...

    In the early versions of VAX/VMS, the whole of the kernel address
    space was readable from a nonprivileged user program. And then there
    was this feature in a rCLmessage sectionrCY (a shareable library
    containing diagnostic messages indexed by status code) where its
    header contained executable code that would be entered *from the
    kernel*, in privileged mode ...
    --- Synchronet 3.22a-Linux NewsLink 1.2
  • From scott@scott@slp53.sl.home (Scott Lurndal) to comp.arch on Thu Sep 3 14:41:40 2026
    From Newsgroup: comp.arch

    Lawrence =?iso-8859-13?q?D=FFOliveiro?= <ldo@nz.invalid> writes:
    On Wed, 02 Sep 2026 08:11:15 -0700, Andy Valencia wrote:

    This brings back memories of MIPS' K0 and K1 registers. From
    non-interrupt code perspective their value could change
    asynchronously, as they were there to be scratched upon by the
    lowest level of interrupt and trap entry. It always struck me as a
    covert channel, though I never came up with a way to use it.

    People were so much more na|>ve back then ...

    In the early versions of VAX/VMS, the whole of the kernel address
    space was readable from a nonprivileged user program.

    You'll need to support this statement. It wasn't true with
    VMS 2.0.
    --- Synchronet 3.22a-Linux NewsLink 1.2