Liste des Groupes | Revenir à c arch |
On 2025-04-01 7:24 p.m., MitchAlsup1 wrote:One of the reasons I went with treating the register file and thread-On Tue, 1 Apr 2025 22:06:10 +0000, Robert Finch wrote:The CPU does not do pipe-lined burst loads. To load the cache line it is
>On 2025-04-01 2:51 p.m., MitchAlsup1 wrote:------------------On Tue, 1 Apr 2025 4:58:58 +0000, Robert Finch wrote:>>>>
It is looking like the context switch code for the OS will take about
3000 clock cycles to run.
How much of that is figuring out who to switch to and, now that that has
been decided, make the context switch manifest ??
That was just for the making the switch. I calculated based on the
number of register loads and stores x2 and then times 13 clocks for
memory access, plus a little bit of overhead for other instructions.
Why is it not 13 cycles to get started and then each register is 1 one
cycle.
>
two independent loads. 256-bits at a time. Stores post to the bus, but
I seem to remember having to space out the stores so the queue in the
memory controller did not overflow. Needs more work.
>
Stores should be faster, I think they are single cycle. But loads may be
quite slow if things are not in the cache. I should really measure it.
It may not be as bad I think. It is still 300 LOC, about 100 loads and
stores each way. Lots of move instructions for regs that cannot be
directly loaded or stored. And with CRs serializing the processor. But
the processor should eat up all the moves fairly quickly.
Deciding who to switch to may be another good chunk of time. But the
system is using a hardware ready list, so the choice is just to pop
(load) the top task id off the ready list. The guts of the switcher is
only about 30 LOC, but it calls a couple of helper routines.
Les messages affichés proviennent d'usenet.