![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
scott wrote:
>> and another thread that waits to receive a signal, and then does all
>> the other stuff. But noooo, the timing accuracy has increased, but
>> it's still ticking too slowly.
>
> If you can call API functions, call QueryPerformanceCounter from
> Kernel32.dll. It is pretty much the ultimate in terms of useful timing
> accuracy and resolution under windows. It only takes one parameter (a
> pointer to a 64-bit signed integer) so should be easy to set up if you
> don't have the header.
http://msdn.microsoft.com/en-us/library/ms644904%28VS.85%29.aspx
"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.
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Mike Raiford wrote:
> Ludicrously difficult is programming in machine code for a processor
> that doesn't yet exist's micro-ops. ;)
If it makes you feel any better...
http://en.wikipedia.org/wiki/6502#Bugs_and_quirks
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. ;-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> Ludicrously difficult is programming in machine code for a processor that
>> doesn't yet exist's micro-ops. ;)
>
> If it makes you feel any better...
>
> http://en.wikipedia.org/wiki/6502#Bugs_and_quirks
>
> 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. ;-)
FWIW when Acorn designed the original ARM processor, one person designed and
simulated it on a 6502 before starting actual hardware design. IIRC it only
took a very small number of people in total (like 5 or 6) to design the
hardware implementation.
According to wikipedia over 10 billion ARM cores have been built, I bet they
never imagined that when they were sat at their 6502's designing it back in
the 80s :-)
Post a reply to this message
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
> "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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
>> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |