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

Depending on your flexability with the term "the same," yes.

Not necessary in an XT system. The cascaded PIC was used to expand the number of interrupt sources in the AT. That is, it was AT relevant rather than 286 relevant.

"In 1986, the XT/286 (IBM 5162) with a 6 MHz Intel 80286 processor was introduced. This system actually turned out to be faster than the ATs of the time using 8 MHz 286 processors due to the fact that it had zero wait state RAM that could move data more quickly."

The company I worked for at the time had a couple of these.

My vague recollection is that the 286 in the XT/286 was just used as a fast

- Bill

Such as?

I disagree. I consider Haskell to be much closer to Prolog than it is to Fortran, both being declarative languages.

The XT286 had fewer and smaller expansion slots, a smaller motherboard, and a slightly different keyboard than the AT. There is no requirement for a second PIC built into the 286.

Steve N.

It isn't just about syntax, but semantics.

OoO on the x86 is complicated by having one of the strictest memory consistency models of any modern CPU, limiting the ability to re-order memory accesses and requiring a larger store of pending instructions.

It also means that multi-threaded code developed and tested on x86 often needs additional effort (adding memory barriers) to get it working on other architectures.

Try some of the hardware design languages, for a start!

You would be amazed at how much more a declarative language Fortran is than languages like C and C++! To call it an imperative language is over-categorising.

Also, when I was involved with Haskell, it assuredly had a control flow model, in a way that (much of) Prolog didn't. I don't regard the functional/imperative difference as being as fundamental as the proponents of the former claim.

But, what the hell? This is a value judgement, and I have always regarded semantics as more important than syntax - unlike most of the people involved with language design.

Regards, Nick Maclaren.

This is true for the gates that are pushed to the max (transistors with thin-oxide gates, low Vt). Not as much for caches. The switching power term still applies, though.

Thanks, your comments are at a useful level and have useful detail.

Regrettably I don't think you need fast reaction speeds to see the GUI button push phenomena you mention.

If you want yet another area to worry about, consider the ways that many people seem to be implementing systems with "web-services" technology. Typically, if pushed, they'll dimly remember one or two lectures on "distributed systems" and their inherant problems - but they don't connect those with their "web services". If pushed harder so they make the connection, they'll still manage to avoid thinking about what they're building, and will "justify" that by presuming that "the frameworks take care of everything, so that it just works".

But then I'm also old enough to remember when people refused to believe in hardware synchroniser failures due to metastablity. Its deja vu all over again :(

snipped-for-privacy@cam.ac.uk wrote in news:gpg163$quq$ snipped-for-privacy@soup.linux.pwf.cam.ac.uk:

Okay; I'll concede that those are radically different to most programming languages. I'm unsure if it's even fair to consider them as programming languages; they're more like data languages. Although I suppose you can consider an emulator to be an interpreter.

To the extent that they are programming languages, they would probably fall into the declarative family.

What control-flow model?

Monads aside, Haskell evaluates expressions; there isn't any control to flow. Issues such as ordering and short-circuit evalutation are meaningless in the absence of mutable state.

The evalutation strategy is an implementation detail, and only matters insofar as it affects time/space complexity, plus some corner cases such as unsafePerformIO.

I'd suggest that you haven't used functional languages enough, then. The absence of mutable state makes a significant difference to the way that programs are written, and an even more significant difference to the amount of freedom the implementation has regarding evaluation strategy.

Well, I struck lucky! It's not an easy thing to explain.

Interesting. Most of the people I speak to claim that they never see them, even when I have just seen them trip over the effect.

God help me, yes! I was at a "Grid" workshop, and I tried to get one (ANY!) of the project leaders to accept error detection as a work item - I said that I was happy to do much of the work, but wasn't prepared to negotiate for a new project. They all said the above, and I explained that there was a serious, fundamental flaw in their design, where no response was indistinguishable from refusal.

I said that an ATM or business might try to validate a card, go to a broker, which failed to get through. The broker then relies "no", so the ATM or business reports the card to the "bad debt" line. I was told that the banks' protocols prevented that.

This is an example of what I have just said to Stephen Sprunk. The system is designed to cater for small numbers of such events but, if there were a million at once, it would fail (not enough staff). And, if another million happened before the first million were cleared, the whole system would collapse. No more use of cards to pay debts or extract cash ....

And again and again and again and again ....

The only thing that people learn from history is that nobody ever learnt anything from history.

Regards, Nick Maclaren.

Internet

indeed... the internet puts the bytes in integers in the opposite order to intel x86 processors.

The Pascal days are long gone. Originally Office compiled Pascal to p-code, which was interpreted at runtime; later they rewrote in C, still compiled to p-code, and now the C is compiled to native code.

If Windows was ever Pascal, it was in the 1.x or 2.x days; 3.x and later have been all C, AFAIK.

Not the point. If you want everyone to switch to some new chip that can only get is performance when running code written in functional languages, it matters what language your SQL server is written in, whether you wrote it or not.

Widely deployed? The latest survey I can find (Netcraft, Feb 2009) shows that over 90% of web sites are running Apache, Microsoft, or Google servers -- all written in C. The names "Tomcat" and "Glassfish" don't even show up on their list.

I wouldn't be surprised at all. Going by Wikipedia's list of SQL servers, many of the newer ones are indeed Java, but several that were first released in the last few years are written in C or C++.

C has an enduring reputation as being fast/efficient, whether that's true or not, and that has an effect on the language that folks choose for performance-critical projects like web servers and SQL servers that are intended for high-volume use. Go ahead and use that Java web server when you're getting a few hundred hits per hour; when you start getting a million hits per second, though, I bet you'll find your only options to handle that are all written in C...

Provided that the performance and reliability were equal, and I could still access that API from C? I probably wouldn't care. Actually, I'd be very interested to understand how you managed to pull it off, because my gut is screaming "that's just not possible!"

Still, most CPUs today are designed to run C as easy to implement as possible, documented in terms of C, etc.

In theory, one could rewrite all those compilers and interpreters to output something else, and design CPUs to run that something else. But, absent a massive increase in performance for all types of code, what are the odds anyone is going to bother? We have a hard enough time getting people to switch from one C-oriented ISA to another, and that's trivial in comparison...

"Almost" being "until you get to the performance-critical parts". The core of the JVM itself is in C; the native libraries that the Java libraries call (for functions that _can't_ be implemented in Java), the OS, etc. are all in C. Dig down deep enough in nearly any language on nearly any system, and you'll eventually run into C -- and, below that, you'll find a very thin layer of assembly.

My understanding is that it's written in C and/or C++.

They do now, but they're still calling functions written in C if you dig deep enough.

Hmmm. This is where my head starts to hurt. I can understand your example, because I can see how a compiler/interpreter written in C can implement that feature even though C doesn't have it (well, isn't guaranteed to have it).

I have a hard time extending that to more fundamental concepts, though, because I see all of the features in more "advanced" languages in terms of how they'd be implemented in C under the hood -- things that _can_ be done in C (however ugly) but just usually aren't.

And here we get to the critical points. I just don't understand how a C program (i.e. the VM or interpreter) can implement true threads in any other way than with the C threads it has available... For that matter, can someone provide a fairly simple explanation of exactly what's broken in the C threading model? Keep in mind that it's the only threading model I've ever known, so what you consider broken may be something I consider an inherent characteristic of threads and thus not a "problem"...

What I was responding to was "incrementally different", which I interpreted as evolutionary change; all of the examples you give would be considered revolutionary change.

I played with Scheme in a freshman-level CS class, I briefly tried learning LISP, and I'm now going through a tutorial on Haskell. Interesting languages, all of them, but I just don't see (yet?) how one could build, say, an SQL server or a GUI word processor with them.

Heck, SQL was hard enough for me at first; changing my mindset from the imperative programming languages I'd been using since I was 5 years old to a declarative language was hard -- but there were lots of examples of real-world applications out there, so I just copied-and-pasted until it sunk in. A functional language is a similar paradigm shift, and I sorta get it, but I don't have any useful examples to work with...

And how many professional programmers are actually familiar with functional languages and how to build the large-scale programs that would benefit from better parallelism? Most that I know will happily debate which imperative language is the best for days on end but just roll their eyes and leave the room when someone starts talking about the benefits of LISP et al, perhaps because the proponents of such never manage to explain themselves in ways that imperative programmers understand. The religious fervor that often accompanies their diatribes doesn't help either...

For libraries that work entirely (and I do mean 100%) in user space, sure; those languages have gained enough features over time, and enough programmers, that native solutions will eventually be written (if only for reasons of "purity").

However, any Perl/Java/PHP/etc. library for, say, sockets will, if you dig deep enough, eventually end in a wrapper around C system calls. In theory, one could add native syscall support to those languages, but I've never seen it done. If the OS were written in those languages, it'd be a lot easier -- but you _can't_ write an OS in those languages for a conventional CPU. They simply don't have facilities for the necessary low-level control like C does. Heck, at the deepest level, even C doesn't have it -- but support for embedded assembler is pretty much a given in C/C++, while lacking such is a "feature" of more "advanced" languages.

I've often said that they key to C/C++'s success was/is that you can write both portable, high-level code and non-portable, low-level code in the same language and even mix them in the same program; every other language seems to be only capable of one or the other.

Not just tags but the cache SRAM is been accessed on every read/write.

BTW, I know a person who actually designs superscalar MIPS processors. He is a professor in the local university. One of his previous works was about the power consumption; specifically predicting and identifying the "hot" spots. I will probably see him during a week; hopefully he can put some light on the problem.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

You're nuts.

I "know" someone who developed high-performance OoO superscalar processors too. Nothing as mundane as MIPS, though.

Trolling in person can get you into trouble.

Actually, he's kind of right. It depends on the cache organization, of course but in most high-performance designs, for an instruction fetch or a load, one accesses:

1. the tags and
2. all the ways of the set then selects the appropriate way (if there is a cache hit).

E.g. if the cache is a 4 way cache 16 byte lines and the processor is trying to access a 4 byte word, it would read the 4 tags and _at_least_

One could design the processor to access the tags first, then based on the hit resolution, access only one of the ways. However, this adds extra cycles on the load/ifetch path, so a high-performance design would not do this.

If you're really designing for power, you also have to account for:

- LRU structures.

- TLB logic.

- parity/error-correction logic (for stores).

That's not what the moron said.

No, somebody tried to cut him some slack and tell him that's how it works in an earlier post (which I'm not going to try to track down). He was adamant that the *whole* SRAM is active.

I've seen that called a "phased cache".

snipped-for-privacy@cam.ac.uk wrote in news:gpik0t$g6m$ snipped-for-privacy@soup.linux.pwf.cam.ac.uk:

Oh :( I'd vaguely hoped the Grid mob was slightly more clued up :(

When I start thinking about the web services world and their multiple layers of reliable/unreliable synchronous/asynchronous protocols, I want to weep.

And then all we need is add in the youngsters that believe that you can "inspect[*] quality into a product", and it is clear that, to quote Fraser in Dad's Army, "we are all doomed, doomed I say".

So did I :-(

One can laugh, cry or scream. None does much good ....

Indeed we are!

Regards, Nick Maclaren.

You _can_ inspect quality into software [*]

John