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

[[email protected]]

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.

 

[Vladimir Vassilevsky]

John Larkin wrote:

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.

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.

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?

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


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

 

[[email protected]]

Interrupt clashes?

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

Oh. Don't do that.

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.

 

[[email protected]]

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

Now, THAT is very true!


Regards,
Nick Maclaren.

 

[[email protected]]

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

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.

 

[Alexei A. Frounze]

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

Several possible solutions to that:
1. ask to write some code right on the spot, but choose a problem
appropriately: shouldn't be very hard to understand, nor should take
long to write
2. before they come to the interview, just a day or two in advance
give them a problem to write a solution for. Cancel the interview if
the code is too bad. Yes, there's an issue here, how do you know if
they got the solution themselves or somebody or something helped them?
Also, in this case your problem is more likely to appear on the
internet or it will make it there faster.

It would be ideal to see their home or open projects. I actually
wonder, if it's possible to be a good programmer and never have such
projects.

Alex

 

[Joe Pfeiffer]

One of the guards at Cincinnati Electronics was bragging about how
secure the pushbutton door locks were, so i walked over to it, took a
quick look and punched four buttons and opened the door. The head of
security demanded to know who gave me the code, since the door I opened
had nohing to do with my department. I smiled and told him, The
janitors. Which one? All of them. They are too lazy to keep those
fancy locks clean, and I could tell by looking which buttons to push,
and in what order. He didn't believe me, so I walked down the hall,
opening one door after another, each with a different combination. Then
I explained how to spot the combination and he turned red.

I can see "which buttons", but how did you get the order?

 

[Alexei A. Frounze]

I can see "which buttons", but how did you get the order?

First buttons were the dirtiest?

Alex

 

[[email protected]]

You use asynchronous processors?

Of course. So do you. So does everyone else posting here.

You don't need asynchronous logic for a processor to be asynchronous
and, in fact, I said 'machine' (and you don't need asynchronous
processors for a machine to be asynchronous). That's been the case
since the early 1960s, and has been common knowledge even among
non-experts for well over a decade.


Regards,
Nick Maclaren.

 

[[email protected]]

I do all my really hard-core/low-level programming with pen&paper: It is
the only way I know to write something so that I really know if I
understand all the issues or not.

As I am a REALLY slow handwriter, and have difficulty in reading
what I have written, I tend to use a computer. But that means crude,
ad-hoc pseudo-code and flow charts in an editor screen. If the task
is really tricky, I then write that up in semi-formal pseudo-code,
or ad-hoc 'standardese', which can be included as comments.

Coding is then the FOURTH stage[*]

Most of my "production" code is perl glue logic, which I'll happily sit
down and just write, but that's because there's far less actual thinking
involved.

Yes. Except Python, shell, Fortran and C in my case. I am just doing
it for Mathematica, but I don't need a description of how to do mere
powering and exponentiation, even in symbolic form, as it's more or
less engraved on my brain. Using Mathematica isn't :-(


[*] The first being the basic mathematical design, which has to be
done in one's head, on scrappy bits of paper, exploratory programs
and whatever else is needed to design a new algorithm.


Regards,
Nick Maclaren.

 

[Bernd Paysan]

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.

They probably have no joy in writing programs - poor guys.

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

Styles differ - from your other posting I see that you have some special
expectations. I find most code ghastly, too, but maybe for different
reasons ;-).

A program should start with context: who wrote it when, what it does,
what compiler/processor it's for, what is its revision history,
anything else that would be useful. And it should be carefully
commented alongside the code. A quick "coding" test won't show that.

Hm, a significant part of what you are looking at here is in the VCS, not in
the source. Like who wrote it when (blame command), revision history (log
command). Programming is about using tools. Not using a VCS is worse than
just writing ghastly code.

Comments? Depends on the strategy. For some projects, literate programming
is appropriate - e.g. you teach the user how to write such a software, and
understand the rationale behind. If you do test-driven development, your
documentation would be a spec plus tests. If you write a library, you would
use something like doxygen, where you document the use of each function
together with its implementation. The purpose here is to produce a user
manual out of the source code.

Actually writing in plain text what you already wrote in the programming
language (typical assembler-style along-side documentation) is IMHO not
good style for high level languages. Using proper function and variable
names helps a lot, more is only for the reader who doesn't understand the
programming language. This is pointless most of the time - a programmer
must understand the programming language he uses and read it as fluently as
English text. Comments like

a += c; // add c to a
foo(a, c); // call foo with parameters a and c

don't add any value, except if the program is meant as beginner's
introduction into this particular programming language. Most projects
shouldn't fall into this category.

Most of the code we see is just a jumble. You have to figure out what
version of which language it's in (C? C++? Java? Python?) by examining
it line by line. Ditto trying to find out what it's supposed to do.

Language should be already identified by file name extension - what it is
supposed to do (briefly) by the file basename - at least for the smaller
programs you could discuss at an interview (larger programs might have
code-named parts, where you can't see function from filename. My widget
library is called MINOS, the widget editor Theseus - the programs live in
files with these names - of course, the first line in these files describe
briefly what it actually is). When you look on printouts, use
frame-generating software like a2ps (including syntax highlighting).

 

[Ken Hagan]

It would be ideal to see their home or open projects. I actually
wonder, if it's possible to be a good programmer and never have such
projects.

I don't see why not. If you have an interesting enough job to satisfy your
enthusiasm for programming, why would you not spend your home time on the
other things that interest you?

 

[Alexei A. Frounze]

I don't see why not. If you have an interesting enough job to satisfy your  
enthusiasm for programming, why would you not spend your home time on the 
other things that interest you?

Theoretically that's possible. Practically, it doesn't seem like
everyone gets the right job, not all the time at least. Sometimes you
have to fight for the interesting job (on the market or already on the
job). On some projects and in some companies you grow beyond your
project and it's not satisfying anymore. Or your management won't let
you do some cool stuff because to them that's something they don't
understand or something unnecessary or they want/need you to do X, not
Y. Sometimes you're tied to a job for a reason and you don't quite
enjoy what you have to do. In those cases if you're a programmer at
heart, if you have some free time on hand and don't have many other
things to do, you'll do some programming work elsewhere for pleasure,
to grow, etc.

Alex

 

[Alexei A. Frounze]

That won't tell us what we want to know.

A program should start with context: who wrote it when,

Um, if it happens before your eyes, that's probably too much to ask
for an exercise.

what it does,
what compiler/processor it's for, what is its revision history,
anything else that would be useful. And it should be carefully
commented alongside the code. A quick "coding" test won't show that.

Unless you're very strict with that (and you may be due to contractual
obligations), solid code is much more important than those little
bits. Don't get me wrong. Comprehensible comments are good and at
times necessary. What I'm trying to say is, if the code's logic is bad
or convoluted or based on wrong assumptions or the code's too fragile
or it's often missing the necessary error condition checks, then no
amount of comments or revision history will help. And it's fairly easy
to give problems where you naturally expect certain design decisions
and implementation details, including those checks. And that's IMO the
first thing to look at.

Most of the code we see is just a jumble. You have to figure out what
version of which language it's in (C? C++? Java? Python?) by examining
it line by line. Ditto trying to find out what it's supposed to do.

Crap.

You don't hire just anybody, do you? I think the scope of project
and the work you're planning to give to the new employee already
implies certain languages. And so does a resume. Anyhow, you can
explicitly communicate the requirements, including the acceptable
language options and the fact that the code must contain a comment
explaining what is used to build it and how.

Alex

 

[Alexei A. Frounze]

It isn't:

The only way to become really good at anything is to practice, and
practice is a lot easier to keep up if you like doing it.

The rule of thumb seems to be 10 years/10 k hours.

This is interesting. I've seen such a figure somewhere recently and it
seems like it's about right.

I do all my really hard-core/low-level programming with pen&paper: It is
the only way I know to write something so that I really know if I
understand all the issues or not.

I prefer a pencil or a writing board so I can redo it.

Most of my "production" code is perl glue logic, which I'll happily sit
down and just write, but that's because there's far less actual thinking
involved.

If the language frees you up from thinking about things you don't
really want or need to think, it's great. I think Perl has some merit
here (compared to C or ASM.

Alex

 

[Alexei A. Frounze]

I do all my really hard-core/low-level programming with pen&paper: It is
the only way I know to write something so that I really know if I
understand all the issues or not.

As I am a REALLY slow handwriter, and have difficulty in reading
what I have written, I tend to use a computer.  But that means crude,
ad-hoc pseudo-code and flow charts in an editor screen.  If the task
is really tricky, I then write that up in semi-formal pseudo-code,
or ad-hoc 'standardese', which can be included as comments.

Coding is then the FOURTH stage[*]

Most of my "production" code is perl glue logic, which I'll happily sit
down and just write, but that's because there's far less actual thinking
involved.

Yes.  Except Python, shell, Fortran and C in my case.  I am just doing
it for Mathematica, but I don't need a description of how to do mere
powering and exponentiation, even in symbolic form, as it's more or
less engraved on my brain.  Using Mathematica isn't :-(

[*] The first being the basic mathematical design, which has to be
done in one's head, on scrappy bits of paper, exploratory programs
and whatever else is needed to design a new algorithm.

I find it better to first write down a complicated (or big) solution
on paper or on the board using diagrams, the formal/math language and/
or my own notation, things that you can rarely get fast with a text or
any editor, unless you know everything beforehand, which you don't.
Then it can be transformed into code comments and/or added to the
documentation (including as-is or photographed.

Alex

 

[[email protected]]

I find it better to first write down a complicated (or big) solution
on paper or on the board using diagrams, the formal/math language and/
or my own notation, things that you can rarely get fast with a text or
any editor, unless you know everything beforehand, which you don't.

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

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


Regards,
Nick Maclaren.

 

[Alexei A. Frounze]

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

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

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

 

[Bernd Paysan]

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

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?

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

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.

Horrors!

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.

 

[[email protected]]

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?

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.