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