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

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

>> 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

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