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

[Alexei A. Frounze]

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.

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

 

[[email protected]]

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. ...

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.

 

[Alexei A. Frounze]

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!

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

 

[[email protected]]

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.

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.

 

[Alexei A. Frounze]

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 ....

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

 

[Jan Vorbrüggen]

All the processors I use are connected to crystal oscillator clocks,

and they all do every internal state transition on rising clock edges.

Nope. In particular, most of the multipliers in processors in the past
10-15 years have at least sections that operate asynchronous logic. They
do present a synchronous interface to their "users".

Jan

 

[Bernd Paysan]

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

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.

 

[Nobody]

However, using telnet these days is just foolish when SSH is so
ubiquitous...

Telnet still has its uses on devices which don't have the resources (CPU
or memory) to implement SSH. The lack of security isn't an issue if such
devices are kept on a restricted network (along with TFTP, SNMP etc).

 

[Vladimir Vassilevsky]

The CPUs from FreeScale can be overclocked surprisingly high: the MC9S12
rated at 25MHz goes almost to 70MHz. It seems like the core can go even
higher, the limitation is the lock range of the internal PLL. I wonder
what is the reason for the clock margin to be that high.

That is _extremely_ dangerous, particularly if you claim to sell
bug-free products:

Just the observation: in forums or usenet, people often try to
compensate what they don't have in the real life

I have a good friend (Mike Abrash) who write an article about how he,
during the development of the Quake game, chased a tiny visual glitch
for a _long_ time:

While ago I had PC AT 486DX40 which was overclocked to 50MHz. It worked
perfectly well except for some specific places in "Doom" computer game,
also from ID Software. When a semi-transparent monster came into the
picture, the computer crashed immediately. The problem happened only in
that game, always in that situation, and it was clearly related to
overclocking.


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

 

[Charlie E.]

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. ;-)

Oh, yeah, suspended ceilings pretty much make locks irrelevent!

Had a boss (actually, boss's boss...) who of course started locking
his door, as he had 'sensitive' material in it. However, he was a
great practical joker, and he and one of my co-workers whose cube was
outside his door had a running 'prank war' on.

First, we unlocked the door. We then piled an enter wall of printer
paper boxes (full!) across his office and the door. Since it was near
Holloween, we added fake cobwebs and plastic spiders.

Took him a hour to get the door open again, as there were three rows
of printer boxes behind it!


Another time, we received a bunch of little electronic alarm clocks as
a 'bonus.' We went into my bosses office, and hid them throughout the
piles of stuff he had, all set to different times. The best were the
three we put up in his overhead!

Charlie

 

[Alexei A. Frounze]

That is _extremely_ dangerous, particularly if you claim to sell
bug-free products:

I have a good friend (Mike Abrash) who write an article about how he,
during the development of the Quake game, chased a tiny visual glitch
for a _long_ time:

This thing only turned up while running at full speed, withe optimized
fp code.

He finally figured out that their PC vendor had sold them a white box
machine with an overclocked cpu in it (maybe 100 instead 90 MHz?), and
that this 11% out of spec cpu would pass every single BIOS and vendor
test sw they had, except for the specific case of one particular
sequence of hand-optimized asm code, doing fp multiplication on numbers
with a specific pattern.

I.e. running 11% faster turned out to be the point where a few result
bits from an FMUL could turn out wrong! :-(

It's funny, I had a similar problem in a 3d engine of mine, except I
never found why on the set of seemingly unchanging inputs the same
subsequent floating point calculations done over and over again
yielded somewhat different results and that was visible. Since this
reproduced on several different machines, I'm inclined to think that
either there actually was a bug in my code or there was something
wrong in the execution environment (Windows -- I don't think I tried
that same code in DOS).

Alex

 

[Alexei A. Frounze]

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 <yourname>" 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
3rd generation languages like C) actually know how to use a debugger.
The rest simply stick "printf" statements in the code and try
things over and over because they never learned to use any of
the tools. Maybe IDEs with tightly integrated debugging have
improved this now to some degree, I don't know.

G.

If you have to say that, something's very very wrong where you are or
in the industry. I know first hand that it's hard to get good software
engineers capable of doing low level coding/testing (device drivers,
kernel, optimizing/asm, etc) and paying attention to that kind and
level of detail. If applicants can't use a debugger or write a trivial
program like you described, something's seriously wrong.

Alex

 

[krw]

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.

The next day the janitors were told that every lock had to be wiped
down every day, and get a through cleaning every Saturday. Maintenance
was pissed, for having to recode so many doors, and hundreds of people
had to learn new combinations.

We had five-button "cipher" locks put on our lab doors in the late
'70s. They then alarmed one of the lab doors to make it "more secure"
(every day someone would barge through it, bringing security out of
the woodwork). Security refused to put a cipher lock on the second
door because doing so "would make the lab half as secure". BTW, the
two doors were 20' apart on the same hallway.

In another building we had badge readers on the doors, yes, with drop
ceilings, though they were pretty high so perhaps they wanted people
to break legs getting over. ;-)

 

[Larry Elmore]

Yes, and the clean button was the one that wasn't used.

The ones the Air Force had at sites I worked at had metal shields over
the lock panel (actually 5 rocker switches) to prevent that kind of thing.

 

[krw]

Nope. In particular, most of the multipliers in processors in the past
10-15 years have at least sections that operate asynchronous logic. They
do present a synchronous interface to their "users".

So they _are_ synchronous.

 

[Phil Carmody]

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

No they don't. Unless you use next to no processors at all.

Phil

 

[Andrew Reilly]

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.

I don't think he has. I know that I can't do my initial solution
sketches at a keyboard; I keep notebooks for that: I need to draw my
buffers and vectors, and label their sizes. I need to sketch signal flow
graphs. I need to be able to group dot-point ideas with multi-line
braces, and connect those with cross-page arrows. I need to be able to
break into symbolic mathematics, with all of the greek, subscripting,
matrix notation and whatever other symbology goes with it. I would
dearly *love* to be able to do that sort of thing at the keyboard with
similar facility: then I'd be able to search through it. But I can't, at
least that I know of.

LyX is on the right track, I think, but it's probably a bit constrained
by existing LaTeX document styles, and doesn't (that I know of) have an
interactive/keyboard interface to pict diagrams like it does for
equations. It's quite a while since I used it. Add those few pieces
together with some free-form page layout and you'd be heading towards an
awsome creative tool.

Cheers,

 

[Joe Pfeiffer]

So they _are_ synchronous.

That's *not* what he said.

 

[Chris M. Thomasson]

That is _extremely_ dangerous, particularly if you claim to sell bug-free
products:

I have a good friend (Mike Abrash) who write an article about how he,
during the development of the Quake game, chased a tiny visual glitch for
a _long_ time:

http://www.bluesnews.com/abrash/abrash.pdf

Mike quotes you in this article:

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

Indeed it can!

:^)

 

[Jasen Betts]

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.

There is no need for near synchronous interrupts to be an insoluble
problem.

if someting is not safe, don't do it.