Lack of bit field instructions in x86 instruction set because of patents ?

And the moron thinks *I'm* the troll here.

No, I think you're off topic here.

Phil

Then why don't you STFU and contribute something?

Well, Jan was correct for jumping on it because that statement is total bull crap. Internal states are out-of-sync with the clock due to propagation delays through gates, setup-time and hold-time on the inputs to Flip-Flops, etc... This can all be demonstrated with a little bit of experimentation on a simple series circuit using PSpice.

End of story.

Nathan.

Another Usenet loon pops up its empty head.

Wrong. There are surely many more morons who will want to comment.

A specialist on CPUs named "krw" mentioned:

Yeah, but Nathan is a well known and by LL-coders fully accepted, 'Loon'.

Sure, morons like me who at least know the difference between real hardware facts and (perhaps even CS-certified)-programmers guessing,

For 'modern' CPUs: the time when all CPU internal actions were synchron to a clock chip is already over for a long time. Falling and raising edges may start a full hw-job-queu which must be finished before the next clock transition.

So do yourself a favour and read what's written in the HW-manuals before making yourself look like a donkey. __ wolfgang kern KESYS (lowest level Hard- and software design since several decades)

Bait taken; yet another Usenet loon hooked.

I did. You're wrong. No surprise.

On Mar 28, 2:48=A0pm, "Wolfgang Kern" wrote: ...

I think it's a rather common misconception to think that a Computer Science graduate is superior to another software or electrical engineer who did not take those CS classes formally or in that amount. It's a misconception among everybody, including the CS grad. About 10 years ago I thought myself that those guys in CS are probably doing and learning something cool and useful and getting lots of experience. Yeah, right. Now that I've worked in the industry for a while and interviewed CS grads and saw them at work, I realize how clueless and na=EFve I was. If anything, a degree in CS may probably only serve as a simple indicator of a person knowing how to operate a PC, which nowadays is a rather common trait among high school kids and probably doesn't need any certification much like proficiency in the native language. :) CS degree holders aren't inferior either. A decent electronics engineer doesn't necessarily make a good programmer and I've seen such examples too. What ultimately matters is a good understanding of how things really work and/or the ability to figure out things right when they're not yet known, problem solving skills, actual hands-on experience that can be used right away, good gut feeling for traps and possible mistakes, for the good and the bad in the design, implementation and otherwise, ability to look ahead and foresee things, troubleshooting/debugging skills, curious mind, challenging and putting unverified things, assumptions and assertions to test, desire and ability to learn and improve. A degree doesn't guarantee those things.

Alex

Hahaha! I feel a great honor of having attained such an esteemed compliment.

I will print that line and paste it over my diploma. :)

Nathan.

Lets inject some facts into this thread; after that y'all can return to the usual mix of information, mis-information, talking past each other and name-calling.

1. Most _systems_ today have multiple unrelated clocks. When a unit in one clock domain needs to talk to a unit in another clock domain, the circuit needed to successfully transfer this data is quite often called an asynchronous circuit, probably because when the data is captured is non-deterministic.

1. Most forms of dynamic logic involve a precharge phase in which the circuit is raised to Vdd, and an evaluate phase in which the charge is discharged or not depending on the result. Since electrons tend to leak, after the precharge is completed, there is a finite time period in which the evaluation can be done. Thus, the cycle time has to be lower than this. Processors with dynamic logic have a minimum frequency at which they can run successfully. However, dynamic logic is completely compatible with synchronous logic; the output of a dynamic circuit can always be latched. Dynamic logic != asynchronous circuit.

2. There is another kind of latched circuit described as an asynchronous circuit. Consider the case where the circuit delay between two latches is _longer_ than the clock period. In a normal synchronous design, there would be pipeline latches between the latches, so that the partial results would be latched, and the circuit delay between any two latches would be less than the clock period. However, by careful design, it is possible to get rid of the pipeline latches, and still have the circuit work. [BTW: such circuits are sensitive to the exact clock period, and there is a minimal as well as maximal clock frequency at which the circuit will operate, hence the possible confusion with dynamic logic]

1. In most designs data flows from latch to latch. Generally, for a synchronous design, the clock to those latches is globally distributed from a signle point, which allows tools to compute edge-to-edge delays etc. However, for self-timed designs, the clock of the destination latch is derived from the source latch. In the most straight-forward case, it is a simple delay line guaranteed to have a longer delay than any other combinatorial path from the source latch to the destination latch. Such self-timed circuits are also called asynchrous circuits. There have been experimental processors built using these circuits (e.g. AMULET), which have been called asynchronous CPUs.

You fully deserve it.

A+, no doubt.

CPUs do not have asynchronous interfaces, however. Most are fully deterministic. I know of several that are used in lock-step, even though they contain "asynchronous" (really domino) logic. Lock-step wouldn't be possible if the CPU were non-deterministic.

Resolution may take more than one cycle, but yes it really is synchronous. It's no less "synchronous" than the carry in an adder.

Yes, though this multi-clock path is still synchronous logic; it is externally clocked from a single source.

Which are not commercial products (i.e. OT).

Your first statement is dubious, and the second incorrect.

Any CPU that uses parity on any level of cache, pathway or whatever, and retries if it is wrong, is necessarily asynchronous. Any CPU that has multiple, independently clocked, execution units (not just coresbut including them) is almost certainly asynchronous - consider two events reaching a serialising multiplexer 'at the same time'.

And running non-deterministic processes in lock-step is exactly how many parallel software interfaces (HPF, OpenMP etc.) work. It's not easy, but it's not impossible.

Regards, Nick Maclaren.

Wrong. Parity is checked on clock boundaries. It is by definition synchronous.

Independantly clocked, yes. You do like to change the subject.

And yet another, irrelevant, subject change.

Then what do you do? With parity, you can't recover synchronously and have to retry, which takes time. The effect is that that pathway gets delayed relative to others. Hence the functional asynchronicity of the system.

Regards, Nick Maclaren.

Alexei A. Frounze said it:

I wrote: ...

I think it's a rather common misconception to think that a Computer Science graduate is superior to another software or electrical engineer who did not take those CS classes formally or in that amount. It's a misconception among everybody, including the CS grad. About 10 years ago I thought myself that those guys in CS are probably doing and learning something cool and useful and getting lots of experience. Yeah, right. Now that I've worked in the industry for a while and interviewed CS grads and saw them at work, I realize how clueless and naïve I was. If anything, a degree in CS may probably only serve as a simple indicator of a person knowing how to operate a PC, which nowadays is a rather common trait among high school kids and probably doesn't need any certification much like proficiency in the native language. :) CS degree holders aren't inferior either. A decent electronics engineer doesn't necessarily make a good programmer and I've seen such examples too. What ultimately matters is a good understanding of how things really work and/or the ability to figure out things right when they're not yet known, problem solving skills, actual hands-on experience that can be used right away, good gut feeling for traps and possible mistakes, for the good and the bad in the design, implementation and otherwise, ability to look ahead and foresee things, troubleshooting/debugging skills, curious mind, challenging and putting unverified things, assumptions and assertions to test, desire and ability to learn and improve. A degree doesn't guarantee those things.

Alex

Amen. Many thanks for this clarification __ wolfgang

Nick,

as far as I can understand, you are talking about systems being un-predictable (or even non-deterministic), not asynchronous.

Asynchronous has very specific meanings, which are NOT applicable to many of the examples you have been giving.

I would call them examples of non-deterministic behavior, except that some them are theoretically deterministic, just mind-boglingly complex.

On the contrary! The people who use it in the very restricted sense are the ones who have it wrong. Seriously. The term has been used for longer than modern stored-program computers have been around, and I am using it in an appropriate sense.

I have sometimes said "functionally asynchronous", which is a more precise statement - but see below for why it is an error to distinguish this from so-called 'true asynchronicity'.

And that is your mistake! In the 19th century, mathematicians and physicists were much into determinism, as well as separating true randomness from non-determinism, but 20th century developments showed that was a mistake.

It is provable that it is impossible to distinguish randomness from non-determinism (as caused by viewing one aspect of a very complex system), and there is a philosophical debate over whether even quantum mechanics is random or non-deterministic, based on factors that we do not know how to observe. And, of course, asynchronicity is nothing more than temporal randomness.

This isn't just theoretical, but is the basis of pseudo-random numbers, most of RAS design (in hardware and software), and so on.

In the context of building and using real systems (whether hardware, software, or non-IT), it is a cardinal error to believe that there is a functional difference between randomness, non-determinism and unpredictability.

Regards, Nick Maclaren.

Except that you are posting to comp.arch, where the default meaning of the "asynchronous" is the restricted sense. If you want to communicate with an audience (as opposed to rant at them), you have to use their vocabulary.

Slightly off-topic problem: A batter hits the ball over the boundary. By what amount does the score change?