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

Nope! You've missed something critical ....

Some people can type faster than they can write - and I am one :-)

Regards, Nick Maclaren.

I think I can type quite fast too, but whatever the typewriter or computer is, there are always some buttons missing. :) And when you devise a way to workaround that limitation, you lose time. Now, I can and do think and speak faster than I type. Should a dictaphone be used then? :)

Alex

We do. People make mistakes when integrating stuff, as well. We do so on the source level, rarely on netlist level - we rely that the netlist is correct by formal verification and static timing analysis. But that's an analysis vs. source and constraints, so how do you proof that your source and your constraints are right?

Of course. But when you just rely on proof vs. spec, you miss the bugs in the spec. The last larger project I did was an audio amplifier - this thing not only has to meet the spec, it also has to sound good. And sometimes, that needs the spec to change.

The horrors is more that many people who write software do so without thinking about quality. But whether I write something in C or Verilog makes little difference: Both is source code that gets converted to the actual implementation (x86 vs. gates) by a software tool.

If it helps you, yes. If you have to stop writing every minute or so to massage your wrist for some minutes ause of writer's cramp, it doesn't exactly speed you up!

In any case, what is that about buttons? I have got a configuration where I can conveniently cut and paste text around the page, using the cursor keys or mouse as works best. That gives me a simple ASCII scratchpad, which is fairly close to what I would get with longhand. Yes, I do mathematics in longhand, but more of that is done mentally, anyway, as even normal mathematical notation doesn't always have the right concepts.

Regards, Nick Maclaren.

"Usually" :) That's closer to the reality, Mr. Pompous. Yes. the first board is kinda working but it has to be patched here and there, isn't it?

All a

It depends.

There are the things that have to be researched before been developed. There are the things that have to be perceived before making a final decision. There could be several alternatives; they should be tried to see what works best. Some parts could be unreliable or difficult to get. A product could be used in some weird way, and that could have implications.

Looks like a good work for apprentice: trivial, bruteforcing, most likely without cost, power, size and other constraints. What makes you so proud?

Have you looked into the errata sheets? Pretty much any modern CPU has a long list of bugs.

Just recently Mr. Larkin had a problem with interrupts on 683xx. He complained about it in comp.arch.embedded. So, why not have the code work, too?

It depends.

The conceptually clear stuff works first time. The rev. "B" makes into production. Of course, there could be any number of further improvements, modifications and improvements of modifications. Like, with Chrysler audio system, the rev "B" was actually shipped; however there were over 20 redesigns of hardware and about 10 redesigns of software during 5 years after the initial shippable version.

Nevertheless most of my interesting work is on the "R" side of R&D. So I have to design the things which are not in the books; sometimes pushing the limits of performance; sometimes trying to solve the problem in the most elegant way. It usually takes 2 - 3 attempts to get the critical part of the system to perfection; it could take more then that in some cases.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

ASCII isn't sufficient. Unicode is closer, but still doesn't quite cut it, because it's not just the characters, but also the font, the size, the style and layout. Oh, and I want lines between lines, too. And different geometrical shapes, not just boxes or stylized ASCII-art. :) And it shouldn't be laborious to draw or enter. I like, for example, how Visio docs look, but it's an overkill to drag and drop things and select numerous options and reroute connectors, and fit and tailor everything. Too many movements for seemingly trivial things. I liked a lot then-Star Office plain-text formula editor. If only that could be done with more complex and diverse things just as easily and one wouldn't need many megabytes of software to support that and it would be ubiquitous, just like plain ASCII text itself.

Alex

And you do all that IN LONGHAND? Yes, if you are a skilled artist, who has no trouble doing such things, fine. But most people aren't, and I most definitely am not!

Regards, Nick Maclaren.

The funny thing is, if you make those rare complex things clear (not everything deserves lots of non-ASCII stuff) in clear diagrams/ drawings/etc that leave no room for guessing, you won't only help others understand it, you will say thanks to yourself when you come back to it after a while not remembering much if anything of what you once did. So, for now, what can be done reasonably well in ASCII is in ASCII, and everything else is in the natural language of the problem.

Alex

All the processors I use are connected to crystal oscillator clocks, and they all do every internal state transition on rising clock edges. External events are synchronized to that clock before the processor acts on them.

There's no excuse for metastability failures or for "interrupt clashes."

John

You have most DEFINITELY missed the point! I was talking about the initial, VERY rough, drafting of a solution - that which you throw away when you write the proper specification, before starting to code it. Pencil and paper, or ASCII in a suitable full-screen editor, are the best solutions I know of.

For a proper specification, I agree with you in principle, except for one serious problem. The chances of such fancy specifications being undecodable when you or someone else needs to do so, 20 years down the line and on a system with nothing in common with the one you wrote it on, is very high. If you write things for the long term, fancy formats have so far been an unmitigated disaster.

No, I have no solution to how you write specifications that simply can't be written comprehensibly in ASCII - TeX and Postscript haven't done badly, but come again in 30 years and on a system and with all applications that haven't even been thought of yet ....

Regards, Nick Maclaren.

For seriously tangled non-obvious stuff (as, recently, a serial interrupt service routine) I draw a flow chart, with lots of side notes and register maps and such, on a sheet of D-size vellum, with a proper engineering title block. I never lose D-size drawings, and I can also photograph it and include it in the code release package.

Good programming is just a special case of good engineering.

John

But faster is not the issue. Slow down and get it right the first time.

John

t,

I have a number of drawings for the problems that I solved when I were playing with 2d and 3d graphics. Even though they didn't become any kind of spec (weren't even supposed to), that kind of stuff is pretty awful to do in ASCII, whether throw away or not, and so it lives separate from the code, at least not in the same source file, where the solutions are implemented in code.

Alex

We ship well over 80% of our first-etch, rev A boards.

Sure. Do that.

Of course.

SEVERAL prototypes, and a test-off? That could take years.

Difficult to get can be known in advance. Unreliable is rare these days. We try to use known-good, in-stock parts, or parts with drop-in equivalents. When in doubt, we test new parts to destruction to see what kind of margins we have.

The only way to discover that is to get real units into customers hands. That's the only way to make money, too. But we're different: you charge for engineering, starting day one; we charge for products, and get paid only after working units are shipped.

So read the datasheets of new parts _very_carefully_ and suspect any unusual footnotes or example circuit oddities.

My assembler never makes mistakes!

For certain values of "last moment"... like just before the fifth prototype is done.

You've seen my stuff. We don't do trivial.

Pride is not one of my sins. Really.

But they work, are shipped, and make money. And most of the bugs are in microcode = software!

It does work. The FPGA apparently makes a glitch on the IRQ6 line when I turn the interrupting subsystem *off*. The CPU then takes a "bad irq" vector. I fixed it in the firmware rather than spinning the FPGA release. These things happen. The more careful you are, the less they happen.

As noted, we have different incentives. Engineering is all overhead to us, because we pay for it ourselves. We make money by building and shipping products, so it's crucial that we get them out, working as promised, as soon as possible. Performance is promised, in the form of a manual, before the customer cuts a purchase order.

Our "R" side is little circuits that we do to evaluate new parts and ideas for possible future products. Sometimes these are breadboards, small pc boards, or simulations.

John

John, this sort of approach is perfectly reasonable and no programmer should object to it as a SOP, but I wouldn't immediately ding anyone who didn't have those big formal revision/description blocks if they were writing relatively small chunks of code (say, Most of the code we see is just a jumble. You have to figure out what

Smartass comment: Usually the file extension will tell you that. :-)

(Well, unless you get some "web programmers" who will embed PHP within Javascript within HTML or somesuch!)

Back to your actual problem: Try contacting Jack Ganssle

If you want to see many examples of awful code, visit

---Joel

Nope. In particular, most of the multipliers in processors in the past

Jan

First of all, CPU designer delegate all "difficult" work to the microcode programmers, or in case of embedded CPUs to the firmware programmers. That is for a good reason: It is easier to fix (one mask, or just reprogram the flash), *and* it is less bug prone then when done straight away in hardware. To avoid bugs, KISS is the most obvious way to go. And for hardware design, the way to avoid bugs is: Make the hardware KISS, and move all the complex, but necessary operations to software. That way, you can tape out a GPU with 2 gigatransistors, receive working samples 5 weeks later, and then write/fix drivers that crash and produce crappy output for the entire rest of the device's live.

And second, some recent really problematic bugs haven't been in software, e.g. the Phenom TLB problem.

Indeed. I haven't tested the frames on my house (since that'd be expensive, and the windows are a much easier target anyway), but at my last apartment, I discovered that all it took was a single kick to rip the latch plates out of the frame -- and it wasn't particularly loud, either. Unless someone happened to be watching at exactly the right second, nobody would know how you got in.

Of course, this assumes you lock your doors in the first place, and many people don't -- just like many people have monitored alarms to get the insurance discount but never turn them on.

Telnet may be fine if you require one-time passwords (as some systems I've used do). However, using telnet these days is just foolish when SSH is so ubiquitous...

It turns out you don't even have to give them a problem to solve. I learned years ago that I can eliminate about 90% of applicants for a programming job by asking them to write me a program, any program, using the tool of their choice (on the system they're being hired to work on). It can prompt them for their name and then display back "Hi " or something equally trivial.

The clueless people think this is a trivial task and produce trivial code (all upper case, no formatting, no comments, etc.) the good programmers will be unable to resist putting a nice header, comments, constant definitions as appropriate, etc.

And a surprising number of applicants turn out to be unable to invoke the compiler / linker etc., don't know how to use any editor, or equally absurd things. These are people who managed to talk in the first part of the interview in a convincing manner about all their experience.

Also I have a new twist on this based on the debugger thread. I will in future give people a similarly trivial program with a bug of some sort in it and ask them to debug it. To pass this test they will need to demonstrate the ability to use any debugging tool (gdb, etc.). I fully expect this to eliminate another 90% of applicants as from my experience only about 10% of people (using

G.