 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 3:31 AM, Invisible wrote:
>
> (Unless, of course, you're working with a language which actually has
> built-in support for calling DLLs. Then presumably it *is* trivial.)
>
Any language that uses the pascal calling convention or allows the use
of the pascal calling convention has built in support for calling at
least the system DLL's (results may vary with others, especially C++
dlls that use name mangling and thiscall calling convention. But, if you
can emit machine code, you're golden. ;) Just load ECX or RCX with the
target's address push the arguments on the stack (in the proper order)
and you're golden. ;)
>> So long as your language allows you to set up a block of data with the
>> common data types it shouldn't be at all tricky.
>
> Heh, right.
>
> I still think recording a few keypresses and doing some statistics on
> them is way, way simpler.
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> (Unless, of course, you're working with a language which actually has
>> built-in support for calling DLLs. Then presumably it *is* trivial.)
>
> Any language that uses the pascal calling convention or allows the use
> of the pascal calling convention has built in support for calling at
> least the system DLL's.
Dude, that's like saying...
> But, if you can emit machine code, you're golden. ;)
...oh god.
Hey, you know there are people who solved the Project Euler problems
using only assembly, right? :-P
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 7:41 AM, Invisible wrote:
> Hey, you know there are people who solved the Project Euler problems
> using only assembly, right? :-P
I'm sure there are... Say! That sounds like a really fun challenge!
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 7:29 AM, Invisible wrote:
>>> Oh, wait - you'd need a hex editor to do that...
>>
>> I hear there's a nice one coming out ... some time. Written by a
>> member of this newsgroup, too!
>
> Yeah, there is. Just as soon as I finish writing it. :-P
You're writing one, to? Et tu, Andy?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 7:30 AM, Invisible wrote:
>> Ludicrously difficult is programming in machine code for a processor
>> that doesn't yet exist's micro-ops. ;)
>
> That depends on how complex the processor is, now doesn't it? ;-)
I suppose, but it makes debugging a royal PITA either way ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>>> Oh, wait - you'd need a hex editor to do that...
>>>
>>> I hear there's a nice one coming out ... some time. Written by a
>>> member of this newsgroup, too!
>>
>> Yeah, there is. Just as soon as I finish writing it. :-P
>
> You're writing one, to? Et tu, Andy?
I had a go at writing one, and eventually gave up.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> Ludicrously difficult is programming in machine code for a processor
>>> that doesn't yet exist's micro-ops. ;)
>>
>> That depends on how complex the processor is, now doesn't it? ;-)
>
> I suppose, but it makes debugging a royal PITA either way ;)
Again, depends how complex. ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/8/2010 8:16 AM, Invisible wrote:
> Again, depends how complex. ;-)
OK, How about this one. Coding x86 Machine Language with no assembler.
That's difficult ;)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> On 6/8/2010 8:16 AM, Invisible wrote:
>
>> Again, depends how complex. ;-)
>
> OK, How about this one. Coding x86 Machine Language with no assembler.
> That's difficult ;)
Hell yes. But that's because the x86 system has become ridiculously
over-complicated with decades' worth of backwards-compatibility crap.
(E.g., real-mode exists, even though most desktops spend less than 0.01%
percent of their time running in this mode.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> On 6/8/2010 8:16 AM, Invisible wrote:
>
> > Again, depends how complex. ;-)
>
> OK, How about this one. Coding x86 Machine Language with no assembler.
> That's difficult ;)
At least you only need 3 keys on your keyboard ;-)
http://homepages.strath.ac.uk/~cjbs17/computing/binary.html
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> That's quite nice, but a cursory inspection of the JavaScript code
> reveals how it works: In effect, the first keypress starts a timer. The
> displayed BPM is simply the time elapsed between the first and most
> recent keypress divided by the total number of presses.
>
> Now I'm wondering if I can come up with something a little more
> accurate. (Although, obviously, accuracy is ultimately determined by how
> good your coordination and sense of rhythm are!)
Take a look at the attachments.
The first one shows the normal prediction method - take the duration of
time between the first and last tap, divide by the number of taps. This
gives you the beat period (i.e., seconds/beat). The BPM figure is just
the reciprocol of this (with some conversion of units).
As you can see, if you compare the predicted beat times to the actual
taps entered, there's quite a lot of error. But, more seriously, the
error shows a pronounced linear trend. In other words, the BPM figure is
wrong, causing the taps and the prediction to gradually change their
phase relationship.
Now take a look at the second attachment. This is produced using a
propper linear regression. (Simple least squares, apparently.) Here the
algorithm has quite rightly detected that the first few taps are
horribly out of time, while the remaining ones fit neatly onto a regular
beat grid at 129.98 BPM (verses the 131.72 BPM detected by the other
method).
I notice there's still a slight linear trend to the errors, so maybe the
true BPM figure is actually lower still.
What the first method is doing is basically setting the prediction error
of the first and last tap to exactly zero, and linearly interpolating
between. This works horribly if the first and/or last taps are
particularly out of time. It's basically using 2 data points to detect
the right BPM figure.
On the other hand, I'm not sure, but I'd guess that *least squares*
linear regression probably assigns a large penalty to points with large
errors. In other words, out-of-time points are especially significant.
Obviously what *I* want is for out-of-time points to be especially
*insignificant*. I want to maximise the number of points with low
errors, not minimise the total error size.
Also, I have no idea how to compute a confidence value for the
regression predictions, other than by using the statistics of the tap
time-deltas as an estimate...
Post a reply to this message
Attachments:
Download 'bpm1.png' (25 KB)
Download 'bpm2.png' (21 KB)
Preview of image 'bpm1.png'
Preview of image 'bpm2.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> Now take a look at the second attachment. This is produced using a
> propper linear regression. (Simple least squares, apparently.)
In solomn truth, both the simple and fancy algorithms tend to produce
very similar results, given the same data. Regression fit produces
smaller error values by getting the phase alignment correct, but they
both report roughly the same BPM reading.
Also, they are both equally perplexed by missing / additional beat
signals, so I need to go figure that out...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Also, they are both equally perplexed by missing / additional beat
> signals, so I need to go figure that out...
With your array of times-between-beats, calculate the mean and sd of the
whole array, then remove any entries that are outside of the mean +/- N*sd
before you do your BPM calculation. You can choose N based on the results,
but I guess around 1 should work.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
scott wrote:
>> Also, they are both equally perplexed by missing / additional beat
>> signals, so I need to go figure that out...
>
> With your array of times-between-beats, calculate the mean and sd of the
> whole array, then remove any entries that are outside of the mean +/-
> N*sd before you do your BPM calculation. You can choose N based on the
> results, but I guess around 1 should work.
Yes, that's more or less my plan. I just haven't coded it yet.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I had expected the taps to be approximately correct, but jittered either
side of the correct points by a roughly normal distribution. However,
this is not what I observe.
Take a look at the first attachment. There's an obvious U-shapred trend
in the error graph, and I have no idea why. It appears very, very
frequently though. But aside from that, the errors look much more like a
random walk than a normal distrubition. The timing error in each tap
appears to be highly correlated with its neighbors.
The second attachment shows a similar pattern (although the U-shapred
trend is now inverted). Note the difference in tempo between the two
examples.
I hypothesize that what actually happens is that my tapping is actually
running off an internal mental clock, which is being adjusted by a
feedback loop that keeps it reasonably in-phase with the actual
drumbeat. Hence the random-walk variations.
Of course, it's possible that the music I'm tapping to actually contains
subtle tempo variations. Or that some of these patterns are prediction
errors. I think what I need to do is perform a tapping experiment with a
timing source of known tempo, so I can get genuine error measurements.
(Currently it's tricky to reperate human tapping errors from computer
prediction errors.)
Post a reply to this message
Attachments:
Download 'bpm1.png' (14 KB)
Download 'bpm2.png' (16 KB)
Preview of image 'bpm1.png'
Preview of image 'bpm2.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> I think what I need to do is perform a tapping experiment with a
> timing source of known tempo, so I can get genuine error measurements.
Heh, this is more difficult than you'd imagine.
I wrote a small program that basically does
Get wall time.
Save wall time to file.
Print something to stdout.
Wait X seconds.
Repeat.
The amount of time is computed from the requested BPM. Only trouble is,
when I analysed the resulting data, I discovered that the program is
ticking too slowly. (E.g., I request 135 BPM, but I get 128 BPM.)
So then I tried having a thread that just does
Send signal.
Wait X seconds.
Repeat.
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.
Thing is, what I want to do isn't "wait until X seconds from now", it's
"wait until time X". But there isn't a function to do that. If there
was, I could take the wall time now, compute the correct time for all
future clock ticks, and schedule the thread to run at those times. But
there isn't.
So I started digging through the library source code. Oh, this is fun:
Internally the "wait X seconds" function is implemented using a "wait
until time X" function. But it's private, so I can't call it. Thanks,
guys...
Next plan: Write out a WAV file containing sonic pulses with the correct
timing. Because, let's face it, there isn't much that can go wrong here.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/9/2010 5:18 AM, Invisible wrote:
> I hypothesize that what actually happens is that my tapping is actually
> running off an internal mental clock, which is being adjusted by a
> feedback loop that keeps it reasonably in-phase with the actual
> drumbeat. Hence the random-walk variations.
Am I the only one who thought PLL when I read this?
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> I hypothesize that what actually happens is that my tapping is actually
>> running off an internal mental clock, which is being adjusted by a
>> feedback loop that keeps it reasonably in-phase with the actual
>> drumbeat. Hence the random-walk variations.
>
> Am I the only one who thought PLL when I read this?
No, that's pretty much what I was thinking when I wrote it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> I hypothesize that what actually happens is that my tapping is actually
>>> running off an internal mental clock, which is being adjusted by a
>>> feedback loop that keeps it reasonably in-phase with the actual
>>> drumbeat. Hence the random-walk variations.
>>
>> Am I the only one who thought PLL when I read this?
>
> No, that's pretty much what I was thinking when I wrote it...
I also thought about it when I suggested to write code to find the BPM
automatically.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
> 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.
Well, yeah.
> 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...)
No, you do your processing, then you look at the highest resolution clock
you have and figure out how much *longer* you have to wait, then you wait.
Adjusting for the length of time it takes to figure out how much longer you
have to wait.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> And you actually know how it was wired up internally, do you?
>
> http://www.pagetable.com/?p=39
...Christ that's complicated! o_O
> so now it's an argument more over "what is microcode" than it is
> over whether a 6502 has microcode.
Yeah, well, that figures. ;-)
> I'd say anything that steps thru a ROM with a counter during one
> instruction is probably microcode, myself.
Well, a "ROM" can be just a grid of wires, some connected and some not.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> 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...)
>
> No, you do your processing, then you look at the highest resolution
> clock you have and figure out how much *longer* you have to wait, then
> you wait. Adjusting for the length of time it takes to figure out how
> much longer you have to wait.
Except that figuring out how long you need to wait would *itself* take
time...
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Well, a "ROM" can be just a grid of wires, some connected and some not.
Yes? I was saying something with a program counter that runs mulitple
instructions per CPU instruction would count as microcode, regardless of how
you stored the code it's running.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
>>> 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...)
>>
>> No, you do your processing, then you look at the highest resolution
>> clock you have and figure out how much *longer* you have to wait, then
>> you wait. Adjusting for the length of time it takes to figure out how
>> much longer you have to wait.
>
> Except that figuring out how long you need to wait would *itself* take
> time...
You missed the second sentence of the two-sentence paragraph, didn't you?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Orchid XP v8 wrote:
> Except that figuring out how long you need to wait would *itself* take
> time...
Here's another funny thing:
In CDMA cell phones (at least), not only do they have to figure out how long
they have to wait, they have to keep track of how long different parts of
the chip have been turned on, to compensate for the fact that the crystal
will vibrate at different speeds depending on how warm it is. So if you have
to read two packets before turning off, you have to plan to wake up slightly
later than if you only read one packet before you turned off, because the
chip will be running warmer and faster.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> Well, a "ROM" can be just a grid of wires, some connected and some not.
>
> Yes? I was saying something with a program counter that runs mulitple
> instructions per CPU instruction would count as microcode, regardless of
> how you stored the code it's running.
So if it doesn't use a counter it's not microcode?
As you say, we're just arguing about semantics now. I always thought of
microcode as being a block of ROM (or even some kind of EPROM) which
actual address decode circuitry, so that you can execute jumps and so
forth. By contrast, the CPU I'm designing has no such thing. It's just
that on each clock pulse, a different control line becomes active, and
that line connects to one or more control lines (possibly via logic
gates that pass the signal only if the opcode has certain bits set). I
wouldn't call that microcode; it'd call that "a custom arrangement of
gates".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>>> No, you do your processing, then you look at the highest resolution
>>> clock you have and figure out how much *longer* you have to wait,
>>> then you wait. Adjusting for the length of time it takes to figure
>>> out how much longer you have to wait.
>>
>> Except that figuring out how long you need to wait would *itself* take
>> time...
>
> You missed the second sentence of the two-sentence paragraph, didn't you?
No, I failed to comprehend it.
Even so, I'd suggest that it's more or less infeasible to determine how
long a calculation takes.
Either way, this would be *so much* easier if I could ask for absolute
rather than relative start times...
(I also love the way the internal implementation look like it's likely
to fail if you call threadDelay just before midnight... That's a nice
touch.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 6/11/2010 3:00 AM, Invisible wrote:
>
> As you say, we're just arguing about semantics now. I always thought of
> microcode as being a block of ROM (or even some kind of EPROM) which
> actual address decode circuitry, so that you can execute jumps and so
> forth. By contrast, the CPU I'm designing has no such thing. It's just
> that on each clock pulse, a different control line becomes active, and
> that line connects to one or more control lines (possibly via logic
> gates that pass the signal only if the opcode has certain bits set). I
> wouldn't call that microcode; it'd call that "a custom arrangement of
> gates".
I might be wrong, but my definition of microcode is thus:
A sequence of one or more control signal sets configured to execute the
desired instruction. On mine, for example, the microcode rom is
basically a big LUT allowing for 16 microcode steps each instruction,
since an instruction can have more than one phase:
For example
ld a, [si]
decodes to a series of instructions:
output the contents of si to the address latches
fetch the memory word from that location and store it in the register a
fetch next instruction
(The second can be done is a single step, due to the mux/dmux pair that
allows most registers or busses to be connected to other registers or
busses)
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Invisible wrote:
>>> Well, a "ROM" can be just a grid of wires, some connected and some not.
>>
>> Yes? I was saying something with a program counter that runs mulitple
>> instructions per CPU instruction would count as microcode, regardless
>> of how you stored the code it's running.
>
> So if it doesn't use a counter it's not microcode?
That's just *my* definition. If it doesn't have something serving as a
program counter, I wouldn't classify it as "code" instead of "logic". In the
case of the 6502, it's pretty clear that the T1 thru T6 lines act as a
program counter, and the other bits are acting as the code.
> As you say, we're just arguing about semantics now. I always thought of
> microcode as being a block of ROM (or even some kind of EPROM) which
> actual address decode circuitry, so that you can execute jumps and so
> forth.
Basically. And normally its instructions are wide enough to have one bit per
gating signal inside the CPU (so, a line for "register 1 reads bus", a line
for "register 2 writes bus" a line for "R3 writes to address bus" a line for
"PC reads from data bus", along with selecting the proper ALU unit, etc. So
microcode is not uncommonly 100's of bits wide. And it usually has the new
Micro-PC in each instruction too, so every instruction is a branch.
> By contrast, the CPU I'm designing has no such thing. It's just
> that on each clock pulse, a different control line becomes active, and
> that line connects to one or more control lines (possibly via logic
> gates that pass the signal only if the opcode has certain bits set). I
> wouldn't call that microcode; it'd call that "a custom arrangement of
> gates".
I agree. There's no code there. You have hardwired logic.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> A sequence of one or more control signal sets configured to execute the
> desired instruction.
I guess, depending on how you define "control signal sets" and "configured"
and "sequence", sure. *I* consider it microcode if the configuration is ROM
instead of hardwired logic, and "sequence" implies having something
counter-like to sequence it.
The idea being that all you need to change what instructions a microcoded
CPU supprts is to change the ROM itself without rewiring other gates.
People used to build computers that would load different microcode depending
on the program you were running. The first Smalltalk machines had a
Smalltalk microcode set, so there weren't any "primitives" - the CPU ran
Smalltalk code directly. Other machines could switch between FORTRAN and
COBOL microcode. The original 8" floppies were designed to hold the
microcode for those mainframes.
> n mine, for example, the microcode rom is
> basically a big LUT allowing for 16 microcode steps each instruction,
> since an instruction can have more than one phase:
And how do you step thru those instructions? A program counter type thing?
Then it's likely microcode in my book. :-)
Don't think I'm trying to be authoritative on this one. There's probably
some actual official definition out there that's relatively arbitrary due to
things on the edge of the definition.
--
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:
> Even so, I'd suggest that it's more or less infeasible to determine how
> long a calculation takes.
Nonsense. People do it all the time. If nothing else, do it by
experimentation. Try sleeping one milisecond using the technique, measure
how fast the clock goes, and adjust. You can even adjust dynamically based
on when you wake up. If you wake up 29 microseconds later than you asked,
subtract 29 microseconds the next time.
> Either way, this would be *so much* easier if I could ask for absolute
> rather than relative start times...
Read the absolute time, subtract it from the time you want to wake up,
subtract the length of time you were late last time, and sleep that long.
When you wake up, read the absolute time, subtract it from the time you
wanted to wake up, and store that for the next cycle.
> (I also love the way the internal implementation look like it's likely
> to fail if you call threadDelay just before midnight... That's a nice
> touch.)
What system are you looking at?
--
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/11/2010 11:41 AM, Darren New wrote:
>
> And how do you step thru those instructions? A program counter type
> thing? Then it's likely microcode in my book. :-)
>
well, of course there's some sort of counter. Else how would it work? ;)
> Don't think I'm trying to be authoritative on this one. There's probably
> some actual official definition out there that's relatively arbitrary
> due to things on the edge of the definition.
>
I'm sure there is ... But I don't necessarily think it has to be ROM,
per se, it could be a gate array...
--
~Mike
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Mike Raiford wrote:
> well, of course there's some sort of counter. Else how would it work? ;)
That's what I'm saying. It *is* possible to design logic that doesn't have a
counter like that.
> I'm sure there is ... But I don't necessarily think it has to be ROM,
> per se, it could be a gate array...
Anything that works like a ROM where all you need to do is change *that*
part to have a new instruction set would do. Whether your ROM is implemented
with wires or gates doesn't matter that much to me.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
>> By contrast, the CPU I'm designing has no such thing.
>
> I agree. There's no code there. You have hardwired logic.
It seems we are in agreement then.
(I'm actually wondering if microcode would have been easier though...!)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Darren New wrote:
> What system are you looking at?
The GHC threading library.
The source code looks like it does a POSIX "get time of day" call, and
then uses the "microseconds past midnight" field to determine when the
schedule the wakeup call.
It strikes me that if between now and the intended wakeup time the clock
wraps past midnight, things are going to go wrong. But maybe I'm mistaken...
I'm also not sure if the same thing happens under Windows. It's kinda
tricky to follow all the CPP directives.
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Right. So I just fired up Cubase, imported an audio track, dialed in the
BPM I found from that website, and listened to the click track against
the recording.
Except for some phase-alignment problems, and the click track gradually
going out of phase, the BPM readings I had were very, very close to
being correct. Close enough that it's difficult to figure out whether
they're too high or too low.
In other words, the trivial algorithm the website uses already produces
really very accurate measurements. Nothing to fix here. (Unless you
actually wanted beat-perfect matching, rather than a general estimate of
speed...)
--
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
