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

Sigh, yes :-(

It's like the damn-fool rituals that insurance companies force on householders. What is the point of extremely fancy locks, if the whole door and frame is held in with just a few nails (as it is)? And, in any case, you can get through any normal house wall in a very short time with a sledgehammer or battery-operated cutting wheel - even in the UK, where most houses are double wall brick.

Military tacticians know this one well. How did you get through the minefield? We walked around it ....

Regards, Nick Maclaren.

In alt.lang.asm John Larkin wrote in part:

Yes. A catch-all phrase for errors generated in normally operational code due to the arrival/servicing of interrupt[s]. Often very timing dependant with small activation windows.

-- Robert

Absolutely. Design the code, write the code. Next day, assume it was written by an absolute moron and read it slowly, line by line, looking for the bugs you know are there. Fix the comments and pagination, too. That's the same methodology for designing hardware that works first time.

We routinely design thousand-part 8-layer boards with 100+ MHz clocks, uPs, BGA FPGAs, switching regs, 24-bit ADCs... and have the first board work. Very complex ICs often work at first silicon. So why not have the code work, too?

John

Not really. You don't design hardware by just looking at the schematics. You simulate. You do formal verification, where useful. Etc.

Because code is not simulated. You run it to check it. And usually, it's a hell lot more code than what goes into a very complex IC. E.g. the last more complex chip I did had about 25k LOC of Verilog inside (including comments). It did work "right first time", which meant "a little workaround here and there is sufficient for customer demonstration". We had about 20 bugs to fix, and one of the fixes introduced a new bug (which was easy to workaround, too). The main problem with hardware bugs is lack of realtime simulation - but FPGAs help quite a lot (and so we did - all that stuff went through an FPGA to verify it).

Actually, hardware development - at least in the digital domain - is just another way of writing software. It is not very complex software; 25kLOC is not really large.

It discourages burglars who don't like drawing attention to themselves. Similar to window locks; a burglar *could* just smash the window and climb through the hole, but it's not exactly stealthy.

So exactly why do they specify a lock that cannot be broken with a jemmy or hammer, while not specifying door frames that can't? The noise of doing either is comparable - actually, the frame might be quieter, being wood and not metal.

It's like specifying that passwords must be 16 random characters, changed weekly, and then allowing remote login using telnet.

Regards, Nick Maclaren.

part:

Oh. Don't do that.

John

Rarely, and then we only simulate little subcircuits, never the entire design.

You do formal verification, where useful. Etc.

If you run/test the code to find the bugs, you'll generally miss some of the bugs.

Horrors!

John

There are always the things that could be done better. There are always afterthoughts that come to mind later. There is the special knowledge and experience gained only after the experiments with the rev 0.0 board and rev 0.0 software. There are the mistakes in the datasheets, manuals and silicon. There are the bugs in the compiler, libraries, target operating system and design software. There are the new features that have to be added at the very last moment.

You are not the idiot but a pompous, self promoting tale-teller.

Vladimir Vassilevsky DSP and Mixed Signal Design Consultant

Arrange the following words into a well-known phrase or saying:

Real. Get.

I have posted how an interrupt-free architecture could be designed, and it includes how software could be designed to be the same. But I don't expect to live to see that approach take over, if it ever does. Only a cloud cuckoo academic would design systems assuming a perfect environment which is currently rare to nonexistent.

Regards, Nick Maclaren.

Now, THAT is very true!

Regards, Nick Maclaren.

A computer is a synchronous state machine. Managing state transitions is easy, unless you really want it to be hard.

We've been interviewing programmers for two weeks now. It's astonishing how many really bad programmers there are.

John

That's immortal! Do you mind if I quote you?

Just HOW long have you been in this game? The last truly synchronous machine I used was in 1966 (actually when I started), and the machine had been built 14 years previously ....

Regards, Nick Maclaren.

We lay out a rev A board, release all the documentation, have production build a couple, and usually we can sell them. All a prototype does is force you to check things you could have checked at the design level. Prototypes waste months.

So, I guess your stuff doesn't work the first time. So it probably doesn't work the second time. What's the most prototype spins it has ever taken for you to get to something shippable?

^^^^^^^^^^^^^^^^^^^^^^

That sure looks like an ad and company link to me. Blatant commercialization of usenet! Violation of Charter! You should be ashamed.

John

What kind of questions do you ask them? What's the most absurd response you've heard?

"John, if you just start writing all your software in Java, there'll be 1/10th as many bugs!"

"What? You have zero bugs now? Oh."

He owns the company, so he sets the rules.

I spent more time on the hardware end, dealing with in house programmers who refused to answer simple questions about their code, like which interrupt mode they used, or the sequence they loaded code into configurable hardware. Those answers would have made the testing of complex boards a lot easier. Instead, I received childish answers and insults. One moron stuck his tongue out, then got upset when I reported him to the head of engineering and told them that we weren't going to be able to ship on time, if we didn't get some co-operation and the information we needed.

Inspection means different things to different people, and at different levels. The level John works at makes a big difference, but to some the concept of 'inspection' only means their paperwork will meet the quarterly ISO-9001 audit.

Some code is so toxic that it would scare the EPA. :(

I was a broadcast engineer at the AFRTS radio & TV station at Ft. Greely in the '70s. The supply sergeant went on leave and took his keys with him. The transmitter died as he was leaving the base, and I wasn't going to wait three weeks for him to get back. I took the parts I needed and filled out all the forms for him.

His jaw dropped when he unlocked the supply room to see all the empty boxes and paperwork. How did you get those parts out of the stockroom, I locked the door myself! I went over the wall and unlocked the door. Drop tile ceilings offer almost zero security, if you have a good ladder. ;-)

We ask them to bring some code samples. Some claim that everything they've ever written is proprietary to some company, so they can't show us any. It's like expecting to be hired as a photographer but refusing to supply any pictures.

The code tells the story. Most of what we have seen is ghastly.

John

No, its a good thing, because people will see his bad attitude, and constant attacks on the skills of others, while giving no reason to do business with his company.