Welcome, Guest. Please login or register.

Author Topic: APOLLO 68080 is now HYPER-THREADING enabled  (Read 13239 times)

Description:

0 Members and 1 Guest are viewing this topic.

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show all replies
Re: APOLLO 68080 is now HYPER-THREADING enabled
« on: June 27, 2017, 11:29:10 AM »
Quote from: psxphill;827657
I read his post and he suggested using one register set for user mode and one for interrupt mode, purely to avoid the movem.l overhead when processing interrupts and not actually run code using the two register sets simultaneously.

It should be possible to make movem.l into cached ram pretty instantaneous though. Which would benefit calling ever single function.

The 080 HT allows running two threads at the same time but AmigaOS does not. Hence the idea of off-loading IO tasks (i.e. device drivers) to the second hardware thread.

movem.l is a more difficult instruction to speed up than you believe. It is a multi-cycle instruction like DIV and thus runs only on one of the two pipelines. Furthermore it needs to read up to 15 registers when the register file is limited to only two read-ports per pipeline.

AFAIK in the 080 a movem takes one cycle per register to be moved. A context switch needs to save and load even more data from registers (stack pointer, status), each on entry and exit. If you have interrupt driven IO (e.g. disk, network), you can easily have thousands of interrupts per second and the interrupt mechanism becomes very costly. Using the HT for device handling is a simple way of removing this overhead. Of course, a multi-CPU AmigaOS would be even better but that won't happen easily.
 

Offline grond

  • Full Member
  • ***
  • Join Date: Feb 2016
  • Posts: 154
    • Show all replies
Re: APOLLO 68080 is now HYPER-THREADING enabled
« Reply #1 on: June 28, 2017, 07:18:45 AM »
Quote from: psxphill;827666
I don't doubt that there are limitations of apollo and working round it with hyperthreading is probably easier for him.


Read-ports are a limitation of all CPUs. What's the highest read-port count in a CPU you know of?