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

[krw]

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.

Another Usenet loon pops up its empty head.

End of story.

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

 

[Wolfgang Kern]

A specialist on CPUs named "krw" mentioned:

Another Usenet loon pops up its empty head.

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

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

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)

 

[krw]

A specialist on CPUs named "krw" mentioned:



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

Bait taken; yet another Usenet loon hooked.

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.

I did. You're wrong. No surprise.

 

[Alexei A. Frounze]

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

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

 

[[email protected]]

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

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.

 

[krw]

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

You fully deserve it.

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

A+, no doubt.

 

[krw]

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.

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.

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

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

3. 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]

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

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

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

 

[[email protected]]

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.

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.

 

[krw]

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.

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

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

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

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.

And yet another, irrelevant, subject change.

 

[[email protected]]

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

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.

 

[Wolfgang Kern]

Alexei A. Frounze said it:

I wrote:
....

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

<q Alex>
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
</q>
Amen. Many thanks for this clarification
__
wolfgang

 

[[email protected]]

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.

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

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

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.

 

[MooseFET]

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.

At work, I often put a glossary of the terms I am using in a document
as the first item in the document. Synchronized and triggered fairly
often get included in the list because of exactly the sort of
different meanings we see at work here.

Synchronized or synchronous often means "at a fixed timing with
respect to". This can include things that are timed from a PLL that
is using the signal as input. The internal clock may cycle 10 times
for each input clock cycle. So long as the timing is not slopping
back and forth, the workings are synchronous.

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

The score doesn't change at all. You have to wait for the official
who will set the direction of the score counter for the next clock
edge. :>

 

[[email protected]]

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.

That's STILL a serious mistake! This thread was about the behaviour
of SYSTEMS, including the larger hardware components and CPUs, and
not about the LOGIC they use. The default (and well-defined) meaning
you are referring to applies to logic (at the gate level and a few
levels above) and nowhere else.

It is inappropriate and often incorrect to apply a term that has a
well-defined meaning at one level to much higher level without at the
very least considering whether it makes sense there. And the precise
distinction between asynchronous and non-deterministic, which does
make sense at the gate level, doesn't at much higher ones.

Also, it is NOT true that the term isn't used in the general sense
in computer architecture. Process engineering is not the only thing
that falls into that category, and the term asynchronous has been
used in networking and parallelism for as long as I have been in this
game (and probably longer).

You aren't alone in your confusion, and nor is it new. I have many,
many times in my career tried to explain to people that the fact that
a computer was built out of synchronously clocked logic with precisely
determined effects did not mean that the effects of running identical
computations would necessarily mean that events occurred in the same
order every time.

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

Cheese.


Regards,
Nick Maclaren.

 

[hanukas]

Nick,

let it rest; if they are more interested in pushing you down there is
nothing you can do about it unless they get experience in designing
hardware circuits. It's HARD to get into the mindset of _how_ the
hardware actually works if you have only software exprience. Knowing
assembly is very dangerous as it gives the false impression that you
know HOW things works internally.

Hardware does not work serially. It is made up from many, many
functional units which all work at the same time. They give the false
impression that they work serially, because the interface is serial:
one instruction goes in, result comes out. Right? Wrong.

There is no clock frequency. It is a mirage. All the chips operate at
the speed of light. Electricity goes throgh very tiny tiny transistors
and the flow from various inputs is controlled by the very same
invention. Larger scale logic is built using these tiny things.. these
things make more complicated operations.. these are logic libraries.
Different processes are used to make these millions and billions of
transistors.. these processes have their own logic libraries.. higher
level tools are used to express logic. The higher level presentation
is *different* for different process and libs.. some libs are totally
shit, some are better.

Logic circuit does not need to be clocked, there is a lot of logic
done w/o anykind of clock. The circuit knows the result is ready by
reading a line, if there is current, the logic circuit has completed
one iteration. This kind of logic circuit often takes less power.. but
at SOME level you have to have a clock driving the interface, so that
it is more convenient to talk to outside of the logic. To connect
different blocks together, at least.

There are different classes of logic circuits.. clocked, clockless..
synchronous.. asynchronous.. the interface is clocked and serial for
CPU's because it is very difficult (understatement) to atomize I/O
(among other things) without a clock.

My formal education is in electronics field, but I work writing
microcode and drivers.. and I got into the current job as result of a
very long chain of events which isn't very interesting story to share.
The short version: I gave programming a go when I was 11 or so. It was
fun. I did graphics. Too slow. Use assembly. z80. m68k. mips. x86.
school. arm. pascal. c. c++. ocaml. perl. higher end higher level.
working on graphics. rasterizers. scene graphics. directx. glide.
opengl. games. graphics. consulting. hired by semiconductor firm. been
there ever since. happy end?

The point being, I climb the tree by my ass first.. the software/
assembly mindset is SO WRONG when thinking hardware. You need both if
you're architect; you need to be able to design good hardware and part
of good is that you can write a good driver for it. That's why there
are a lot of software and hardware engineers. senior. staff. you name
it, but fewer architects.

Good night.

 

[Andrew Reilly]

A batter hits the ball over the boundary. By what amount does the score
change?

That would be "six and out". (Backyard cricket rules.)

BTW. I agree with nick. Just because two machines might run from clocks
has no bearing on whether or not they are (or can) operate synchronously
in any useful sense. That's why "synchronization" is such an effort.

BTW part two: common asynchronous domains in (small) computer systems:
rs-232 communications, ethernet packet arrival, keyboard or mouse events,
hard-disk read re-tries, file server contention, etc...

Cheers,

 

[krw]

Then what do you do?

What do *I* do? I do what the specification asks. The bit bangers
here should start by learning something about hardware.

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.

What do you want to do? If lockstep is your intention (as was being
discussed), then both CPUs get the same information so had *BETTER*
have the same answer. If not, pull the plug on the whole mess. It's
broke.

 

[hanukas]

I couldn't come up with an adequate reply

How convenient. =)

 

[[email protected]]

What do *I* do? I do what the specification asks. The bit bangers
here should start by learning something about hardware.

Ah. Sorry, I thought that you were a professional. Many of us who
post to comp.arch are the sort of people who design systems and
write specifications. I was asking what you would do if you were
designing a specification.

What do you want to do? If lockstep is your intention (as was being
discussed), then both CPUs get the same information so had *BETTER*
have the same answer. If not, pull the plug on the whole mess. It's
broke.

Not at all, as you would know if you knew a bit more about such systems.
What needs to be done when one gets a recoverable error is that the
others wait while it retries. When the error is not recoverable, they
use whatever majority voting and decision strategy the designers favour.

The effect is that the results are available asynchronously to the
voting stage, in the case when one or more processor has to retry.


Regards,
Nick Maclaren.

 

[krw]

Ah. Sorry, I thought that you were a professional.

I am, just not a "professional" script kiddie, as you clearly are. I
do hardware for a living, not scripts.

Many of us who
post to comp.arch are the sort of people who design systems and
write specifications.

Many of you on CA are pompous asses, as you are clearly showing here
on SED.

I was asking what you would do if you were
designing a specification.

That's simple. Gather requirements, something you script kiddies
think totally unnecessary.

Not at all,
*ALL*

as you would know if you knew a bit more about such systems.

You're full of shit. I *KNOW* about such systems. Clearly you
haven't a clue about the subject.

What needs to be done when one gets a recoverable error is that the
others wait while it retries. When the error is not recoverable, they
use whatever majority voting and decision strategy the designers favour.

Clueless. You can repeat such nonsense all you want. That is *NOT*
lockstep. Lockstep is a cycle-for-cycle hardware locking. Both units
(at whatever granularity locksteping is done) *must* have exactly the
same information at the same time.

The effect is that the results are available asynchronously to the
voting stage, in the case when one or more processor has to retry.

Clueless.