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

Sadly, having fun at it isn't a sufficient qualification, and I'm afraid there a lots of people in the business (and perhaps the overwhelming majority) who think they are good at it because they enjoy it. This delusion is reinforced by the fact that many can produce large volumes of code that "just works"--well, most of the time.

It would be as if Ford Motor Company or General Motors had been built on idiosyncratic craftsmen cobbling together vehicles in any way that just worked and that the customer would buy.

Sorry if it seems like I'm raining on your parade, but that an enterprise of this magnitude has been built on idiosyncratic enthusiasm would not seem likely to have a good outcome, and it hasn't.

I have the greatest respect for you, but how many of you are there?

Robert.

Our first criterion for evaluating (or keeping) a programmer is that he/she turn out solid, functional, bug-free code on time, so that we can ship quality products. Anybody who wants to have fun on our payroll, without delivering those things, is outta here.

Fun shouldn't be the programming process, fun should be seeing the product work.

John

Not this month, not in Northern California. Run a "programmer wanted" ad in Craigslist and see.

John

I believe I was a bit unclear: I have avoided taking job offers that would let me move to the US and work 60+ hour weeks, even if I could have made a lot more money that way: It would have taken much of the fun out of it.

You need to enjoy something to become really good at it, but the opposite isn't true: Many people enjoy doing things they will never be really good at: Just look at all those people wasting evenings and weekends at the golf course. :-)

Having fun and doing useful work at the same time is not impossible, and I bet most of the engineers who actually get to design new cars love what they are doing.

I have worked for almost 25 years for an oil company working in the North Sea, I do know that a very structured approach is an absolute requirement for any large project.

Unless I have an unknown identical twin, I'm almost certainly unique, just like you and all the rest here.

Terje

--
- 
"almost all programming can be viewed as an exercise in caching"

Funny, debugging with printfs was considered hard-core and using a debugger was considered wimpy.

(I consider most debuggers pretty primitive because they cannot do live updates of the variables I'm watching, so I end up with printfs...).

- Tim

What an experience! :^D

Girls! Now, that's an issue I don't think I will ever be able to figure out completely. Just when you think you got it, they throw a monkey wrench into your line of thought and the gears grind to a halt. Wow. I still get fairly nervous when I am around a gorgeous woman. I don't think I can ever completely break out of that; oh well.

AFAICT, pretty girls seem to be able to wield a power over us that is not fully explainable. Perhaps it breaks down to simple chemical reactions in the brain, but for some reason I think its more than that.

The procreation algorihtm? Na...

;^o

If I did not have fun programming, I would NOT be doing it now. When I was a little kid, I remember having great fun designing all sorts of creative and/or trivial programs and just experimenting and messing around with different ways to code up a solution to a problem. Luckily, I still gain the same level of joy today. My passion is multi-thread synchronization. I really do enjoy it, and have spent many weekends just coding and experimenting. Its very fun indeed!

o.com

er

Debuggers cannot always show all variables because of the optimizations done by the compiler, especially when the variables no longer exist in the compiled code at all or in some form easy for the debugger to work out.

Not everything can be debugged with a debugger because of its influence affecting the timing. In particular, it may be easy to look around the memory after a race condition has happened but not necessarily before or during the event. Logging may help much better. On the other hand, printf's are probably useless when the code gets damaged or the register/stack state gets trashed. And either is pretty bad when the bug doesn't repro consistently and quickly and you don't quite know what's going on.

Alex

This also depends what is a very complex IC ;) I have seen 300+kloc IC designs. Even in software terms that amount of code is quite big already.

On the other hand, with software you don't have to think things like pipelining, clock cycles, timing etc. It's quite easy to do some minor error on a pipeline control that has hundreds of stages to control ;)

--Kim

That is my experience, in 40+ years and many dozens of requirements, languages, environments and tools. The only condition for that to be true is that the requirement is a little too complicated to design in toto in your head.

Regards, Nick Maclaren.

Yes, he has, and so have you. Badly.

Firstly, I did NOT say that ASCII text was good enough for all purposes, and even gave examples of when I don't use it! But, there are a hell of a lot of purposes for which is it perfectly adequate.

Secondly, when it IS adequate, it is often the BEST approach, because it can be sent to other people who don't use your system for comment and editing, with minimal hassle[*].

Thirdly, I pointed out that I (like a fair number of other people) am a VERY slow writer, it causes me actual pain, and I have difficulty reading my own writing.

[*] It is even more important for the second-stage notes, because it can be included as commentary in program source - and can be searched for in a million lines of code written by a thousand programmers over half a century.

Regards, Nick Maclaren.

Oh, really? Have you ever written seriously parallel or asynchronous software? Because you have to worry about all of those :-(

Regards, Nick Maclaren.

ust

OC is

And there're CPUs which unlike x86 do expose their internal pipeline stages to the programmer/software by not inserting internally any wait states to resolve pipeline conflicts automatically. So, in there if the code has a pipeline conflict, the results are poorly predictable. :)

Alex

s a

ound

st

C is

Catapult C is a nice modern tool for designers; you don't have to target a specific process. You just use nice dialogs to balance the environment (frequency, area-vs-performance, latency, etc..) and you can quickly and easily scale the design to different targets. The idea is that you one extreme is optimize for performance and the other is optimize for area .. or anything between those two. Check it out!

You are a bit of a troll, arentcha? Or what is it about the "all internal state transitions" above that you don't understand?

Jan

Catapult C is quite nice tool, but it is geared towards certain style of designs. It is very good with DSP style code, and with other number crunching applications (crypto etc.). But for telecom style of applications it is not very convinient to use.

--Kim

Well, the VMS debugger could do that some quarter of a century ago, so why can't yours today? It could also set watchpoints, conditional breakpoints with various sort of conditions (cf. another follow-up regarding race conditions), and even allows you to debug post-mortem dumps (e.g., those generated from a deadlocked program, again referring to the other follow-up).

So why isn't your toolset as capable as one built so long ago? And no, it can't be because today's processors use more "tricks" than a VAX of that time.

Jan

It wasn't just VMS, either.

Regards, Nick Maclaren.

Indeed. The earliest VAX inspired RTD and PMD appeared on the IBM PC at around that time with the second release of ETH Zurichs 8086 version of their Modula 2 compiler then sold commercially by Logitech. The same company that went on to be much better know for desktop rodents.

It is odd that these powerful tools were spurned in favour of C & printf(). I became convinced that industry did not want reliability or rather did not want to bother training employees to use these toolsets.

Regards, Martin Brown

Our $200 background debugger for the 68332 lets us put breakpoints, single step, patch in hex or assembly, all that. It shows all the registers at every step and has three display windows that can be aimed at regions of memory and display in various formats. If a program crashes, I can look at the crash address on the stack, and the registers, and usually see why immediately.

But the command syntax is obtuse; makes me nostalgic for ODT.

John