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

[Rich Grise]

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

Crafting a perfect line of code for me is as much fun as (probably)
achieving some heroic S/N ratio or some such is to you.

And yes, I write code that works. I'm one of those 90% design, 10%
test guys. ;-)

Cheers!
Rich

 

[Rich Grise]

=?ISO-8859-15?Q?Jan_Vorbr=FCggen?=


It wasn't just VMS, either.

Back in the DOS days (late 1980's), I had a bootleg MSC compiler and
a bootleg copy of "codeview", a visual debugger. I had two monitors,
a monochrome and a CGA, and could interact with the debugger on one
monitor, and view the code under test on the other.

Ah, those were the days! ;-)

Cheers!
Rich

 

[Robert Myers]

Let's face it - we're all whores.

How long would you have stayed at your job if you hated it? Or are you
one of those people who think that being productive isn't allowed to
be enjoyable?

I'm happy to have avoided a flame war so far.

I don't have sufficiently universal knowledge of the world to make
generalizations.

Here's one anyway: fields that are hot attract people with a wide
range of actual talent and integrity. If it's easy to make money
making bad products, people will do it. Mediocre people making bad
products often confuse what they are doing with being productive and
the means they have to do it with talent.

I don't think you have to be unhappy to be productive, but I'll admit
to being skeptical of the gee aren't we (aren't I) smart culture
that's grown up around software.

I've known an awful lot of really smart people, as I'm sure most
everyone here has. Some have been happy, some haven't. For cockiness
and self-congratulation, though, software "engineering" is rivaled
only by financial engineering.

Robert.

 

[Martin Brown]

Not at all:

Did you ever _use_ the Logitech Modula II compiler?

Yes, and for some moderately large projects. It was a reliable
industrial strength compiler for the x86 from about version 2.01 onwards
(c/a 1985). 2.10 was particularly good and stable. I do recall some
serious fun when they suddenly changed the default byte alignment in
structures in one release (which was not a very friendly thing to do).

ISTR it was a slow 4-pass compiler and it's code generator was more than
a bit pedestrian even for the time (but you could add inline code). The
overlay linker was incredibly good, and the debugging facilities were
first rate - comparable with the mainframe tools they copied. Parts of
DEC were actually using the language internally at the time. In the
event of a rare system failure you could be almost certain of finding
the root cause from the PMD in the symbolic debugger.

I did, and it was the most broken piece of programming I've had the
misfortune to work with: Among _many_ other things, the compiler would
generate faulty code for all loop constructs except one (WHILE afair).

To be totally fair, the compiler developers probably knew about most of
these bugs, and were only midway in the process of making the compiler
host itself: The version they sold me were called "V0.3c"! :-(

If you buy a pre-release version 0 bootstrapping prototype what do you
expect? I am surprised they sold you it in that state.

At this time Borland came out with Anders Heijlsberg's Turbo Pascal,
which ran rings around Logitech M2, in pretty much every possible way.

A spin off from the Borland compiler development group headed by Niels
Jensen produced by far the most appealing PC version of Modula2 as JPI.
It's libraries were non-standard, but at the time it's code generation
was state of the art and fast. They developed it independently and it
had some very good vintage versions 1.17 and 3.04 spring to mind.

They had a no-compete clause with Borland for C-compilers and when it
timed out they launched the most horribly buggy C-compiler I have ever
seen. It would crash spectacularly on minor syntax errors (missing ; and
that sort of thing). Code generation was OK if it worked. It did for
them and Clarion took them over (as they used the JPI M2 internally).

These days XDS has probably the most interesting Modula 2 compiler and
they now give it away. It's code generator includes powerful static
dataflow analysis to find path dependency bugs. It can find faults in
old legacy code and has libraries that mimic JPI and PIM3 dialects.

I'd have expected Modula 2 to appeal to electronics engineers because it
provides a means to make robust independent modules that can be trusted
to do exactly what they say on the tin.

Regards,
Martin Brown

 

[Robert Redelmeier]

Let's face it - we're all whores.

No, speak for yourself. Many of us have very few clients.
If you insist, most of us are more like mistresses, kept
women or wives. In some cases, 'til death do us part.

Even that fails because we really don't compete with any
fundamentally different person or one to whom the client
owes allegence.

How long would you have stayed at your job if you hated
it? Or are you one of those people who think that being
productive isn't allowed to be enjoyable?

I won't try to speak for Mr. Myers.

-- Robert R

 

[Rich Grise]

...
I've known an awful lot of really smart people, as I'm sure most
everyone here has. Some have been happy, some haven't. For cockiness
and self-congratulation, though, software "engineering" is rivaled
only by financial engineering.

Well, I hope I'm not one of those elitists. I've been brought into
projects where I had to modify somebody else's code, and I've seen
some pretty terrible code.

But I'm mostly talking about embedded stuff here - I've also seen some
well-written code.

But there is such a thing as "software 'engineering'" - it's just like
"real" engineering - figure out what needs to be done, and figure out
how to get from point A to point B.

Then just do it. ;-)

Cheers!
Rich

 

[Rich Grise]

No, speak for yourself. Many of us have very few clients.
If you insist, most of us are more like mistresses, kept
women or wives. In some cases, 'til death do us part.

I once heard a very wise man say, "Getting married is the most expensive
free piece of ass you can get." ;-)

Cheers!
Rich

 

[krw]

No, speak for yourself. Many of us have very few clients.
If you insist, most of us are more like mistresses, kept
women or wives. In some cases, 'til death do us part.

Well, in 35 years I've been "divorced" twice (was going to say once,
but forgot the year of contracting . After 32+ years I did get
"alimony", though I didn't get 50% of the "estate". ;-)

Even that fails because we really don't compete with any
fundamentally different person or one to whom the client
owes allegence.


I won't try to speak for Mr. Myers.

I will. He fits the metaphor.

 

[krw]

I once heard a very wise man say, "Getting married is the most expensive
free piece of ass you can get." ;-)

Having a child is. ;-)

 

[krw]

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

Hardly. Your statement made no sense in context. Do you think every
transition in a synchronous machine is clocked? It doesn't matter
whether or not there is "asynchronous" logic (I'm assuming you
consider "domino logic" to be "asynchronous") within the synchronous
machine, it is still a synchronous machine.

IOW, it's you who is the troll.

 

[Phil Carmody]

Hardly. Your statement made no sense in context. Do you think every
transition in a synchronous machine is clocked? It doesn't matter
whether or not there is "asynchronous" logic (I'm assuming you
consider "domino logic" to be "asynchronous") within the synchronous
machine, it is still a synchronous machine.

IOW, it's you who is the troll.

But it is you who thinks that an argument about nomenclature of the
whole device, namely "it is still a synchronous machine", is in any
way pertinent to addressing a claim about "every internal state
transition", with an emphasis on the "every".

I.e. you apparently don't know what the words "every" and "all" mean.

Which is far worse than being a troll.

Phil

 

[[email protected]]

But it is you who thinks that an argument about nomenclature of the
whole device, namely "it is still a synchronous machine", is in any
way pertinent to addressing a claim about "every internal state
transition", with an emphasis on the "every".

I.e. you apparently don't know what the words "every" and "all" mean.

Which is far worse than being a troll.

Well, I won't attempt to classify you, but will merely explain why
you are completely wrong. At least as far as the thread goes; I am
not going to waste time on a "who said what" flame war.

A system is built up of multiple components, each of which may be
systems, so it makes very little difference what level we discuss.

If a set of entirely synchronous components is connected by logic
which has a non-deterministic aspect, then the system is potentially
asynchronous. ECC handled by interrupt (whether in firmware or the
operating system) is merely one classic example of such logic, and
remember that ECC can be (and should be!) applied to logic pathways
as well as memory.

Since the early 1960s, almost all 'general purpose' computers have
relied on such logic; since the 1980s, almost all embedded devices
have. A few of them will go to gret trouble to provide apparent
synchronicity, but it is almost always limited and at least some
asynchonicity will be visible to at least some programs.


Regards,
Nick Maclaren.

 

[Ken Hagan]

Some things in engineering are just tedious: checking, testing, parts
lists, test procedures, manuals, ECOs. Most of programming *should* be
tedious: rereading, commenting, testing, documentation, all the stuff
you need to do to get everything right. If you can do all that and
also be an artist, good.

I expect authors, artists and carpenters could make very similar remarks
about their day-to-day activities. Almost any task has bits that are
boring and bits that require creativity. Good practitioners know which is
which. Good engineers show creativity in their design and are ruthlessly
boring in the implementation.

The best programmers I know don't do tricky stiff, don't take risks.
Their code looks very ordinary, except it's well commented, and except
that it just works.

Very few programming languages permit much syntactic artistry, so all code
ends up *looking* "ordinary". If the design is right and has sub-divided
the problem into well-defined and straightforward programming tasks, the
code will look simple. If the design is ill-defined, the code will look
random. If the design calls for bucketfuls of state and complex decisions,
the code will look hopelessly complex.

 

[Phil Carmody]

Well, I won't attempt to classify you, but will merely explain why
you are completely wrong. At least as far as the thread goes; I am
not going to waste time on a "who said what" flame war.

You're hilarious when you're on the run.

Phil

 

[krw]

But it is you who thinks that an argument about nomenclature of the
whole device, namely "it is still a synchronous machine", is in any
way pertinent to addressing a claim about "every internal state
transition", with an emphasis on the "every".

No, the comment Jan jumped all over was:

"All the processors I use are connected to crystal oscillator
clocks and they all do every internal state transition on
rising clock edges."

That is in fact a true statement (if you allow that "rising edge" may
be falling or master-slave). Any asynchronous ("domino") logic states
will still be captured on rising or falling edges. The asynchronous
"states" aren't states at all, any more than asynchronous ripples are
"states".

I.e. you apparently don't know what the words "every" and "all" mean.

Apparently, you're in Jan's remedial reading class.

Which is far worse than being a troll.

IOW, you're trolling for a troll.

 

[Phil Carmody]

The asynchronous
"states" aren't states at all

I think you meant 'the asynchronous states aren't "states" at all',

Which makes you a rather good friend of a true scotman.

Phil

 

[krw]

I think you meant 'the asynchronous states aren't "states" at all',

Which makes you a rather good friend of a true scotman.

And the moron thinks *I'm* the troll here.

 

[Phil Carmody]

And the moron thinks *I'm* the troll here.

No, I think you're off topic here.

Phil

 

[krw]

No, I think you're off topic here.

Then why don't you STFU and contribute something?

 

[[email protected]]

No, the comment Jan jumped all over was:

   "All the processors I use are connected to crystal oscillator
    clocks and they all do every internal state transition on
    rising clock edges."

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.

End of story.

Nathan.