 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> problem is scheduling a thread to run when I actually want it to run.
So you want to schedule real-time threads on a timesharing OS.
Have you bumped the priority of your own process up? Have you scheduled it
to wake a few miliseconds early then busy-loop on the actual hardware clock
until the tick comes? Have you turned off other things that might be
generating interrupts like disk reads?
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/9/2010 9:39 AM, Invisible wrote:
> Note also that the 6502 doesn't have any microcode. It just uses a PLA
> as the control matrix - much like the processor that I'm designing. ;-)
How many instructions are you going to have? Or are you using an IC? You
still have to map the control signals to the op code ;) That's the part
that was giving me fits to debug (though, I'm holding off while I work
on my simulator program, for a while ...)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Note also that the 6502 doesn't have any microcode.
Given how the instruction sets decoded, I'm not sure it's really valid to
say it had no microcode. There were definitely cycles of stepping thru the
code and branching around in the PLA data. I'm not an expert, but it wasn't
really hard-wired logic as such. The HCF instruction, for example, was an
emergent property of the "microcode" interpretation and not something
necessarily intentional.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> "Retrieves the current value of the high-resolution performance counter."
>
> From what little documentation there is, it seems this allows me to
> measure wall-time, really accurately. Which isn't the problem - the
> problem is scheduling a thread to run when I actually want it to run.
Well just start it at roughly the right time and have the thread loop until
it's exactly the correct time.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> Invisible wrote:
>> Note also that the 6502 doesn't have any microcode.
>
> Given how the instruction sets decoded, I'm not sure it's really valid
> to say it had no microcode.
And you actually know how it was wired up internally, do you?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> problem is scheduling a thread to run when I actually want it to run.
>
> So you want to schedule real-time threads on a timesharing OS.
>
> Have you bumped the priority of your own process up? Have you scheduled
> it to wake a few miliseconds early then busy-loop on the actual hardware
> clock until the tick comes? Have you turned off other things that might
> be generating interrupts like disk reads?
My measurements indicate that the interval between ticks is rock solidly
constant - it's just the *wrong* interval. (It's too large.)
I believe the problem is that the library won't let me specify an
absolute time, only relative times. So if I was "wait 100 ms", but the
other processing that the program does takes 1 ms, the delay ends up
being 101 ms, not 100 ms. The fact that taking stuff out of the main
loop made the timings nearer to what they should be supports this
hypothesis. (Although it's always possible that the problem is related
to the size of the quantum that Haskell's thread scheduler is using or
something daft like that.)
Still, since no other API is available, there's not much I can do about
it. (Other than whinge at the developers and see if it gets fixed in the
next release of the library...)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
> Well just start it at roughly the right time and have the thread loop
> until it's exactly the correct time.
I'm not keen on burning shedloads of CPU power just because of a
deficiency in the thread library. But we'll see...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well just start it at roughly the right time and have the thread loop
>> until it's exactly the correct time.
>
> I'm not keen on burning shedloads of CPU power just because of a
> deficiency in the thread library. But we'll see...
Well issue a sleep command at the top until you are roughly at the correct
time, then loop until you are exactly there. You shouldn't be burning more
than 0.1 or 0.2% CPU this way.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Darren New wrote:
>> Invisible wrote:
>>> Note also that the 6502 doesn't have any microcode.
>>
>> Given how the instruction sets decoded, I'm not sure it's really valid
>> to say it had no microcode.
>
> And you actually know how it was wired up internally, do you?
Yes. There was a very interesting article on it showing how it worked,
somewhere. I'll see if I can find it.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> And you actually know how it was wired up internally, do you?
http://www.pagetable.com/?p=39
Actually, I'll grant it's not microcode per se, but it's a table-driven
system with a multiple-cycle-per-instruction clock that steps thru the
table, so now it's an argument more over "what is microcode" than it is over
whether a 6502 has microcode.
I'd say anything that steps thru a ROM with a counter during one instruction
is probably microcode, myself.
--
Darren New, San Diego CA, USA (PST)
Eiffel - The language that lets you specify exactly
that the code does what you think it does, even if
it doesn't do what you wanted.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
