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