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

[krw]

That's *not* what he said.

Yes, but what he said isn't relevant to the discussion, either.

 

[Robert Myers]

The idea above is probably the main reason that I'm still programming
almost purely for fun.

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.

 

[Tim McCaffrey]

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.

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

 

[Chris M. Thomasson]

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

Mike quotes you in this article:

I would like to point out another paragraph from that article series,
about how he showed a girl the Star Trek source code:

"You didn't actually think I was interested in that Star Trek
program, did you?"

[...]

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

The idea above is probably the main reason that I'm still programming
almost purely for fun.

[...]

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!

 

[Alexei A. Frounze]

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

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

 

[Kim Enkovaara]

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

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.

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.

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

 

[[email protected]]

I believe that extra time spent in requirements and design does not
actually increase the time required to deliver the product. In other
words, each day spent (productively) in the requirements or design
phases will reduce the time until completion of the project by at
least one day, and often significantly more than that.

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.

 

[[email protected]]

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.

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.

 

[[email protected]]

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

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


Regards,
Nick Maclaren.

 

[Alexei A. Frounze]

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

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

 

[hanukas]

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

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!

 

[Jan Vorbrüggen]

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

Yes, but what he said isn't relevant to the discussion, either.

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

 

[Kim Enkovaara]

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!

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

 

[Jan Vorbrüggen]

(I consider most debuggers pretty primitive because they cannot do live

updates of the variables I'm watching, so I end up with printfs...).

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

 

[[email protected]]

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

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.

It wasn't just VMS, either.


Regards,
Nick Maclaren.

 

[Martin Brown]

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


It wasn't just VMS, either.

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

 

[Tim McCaffrey]

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


It wasn't just VMS, either.

Indeed, my model for operator console/debugger was on the CDC 6500. The
Console PP could look anywhere in memory at anytime, didn't need the CPUs
cooperation at all.

I do know debuggers, printfs, etc., can change the timing. I use in memory
logging, event counters, watches, etc., etc., as needed when available.
Sometimes, though, you have to debug with nothing but a serial port and no
debug environment...

- Tim

 

[Anne & Lynn Wheeler]

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

Los Gatos used metaware's technology for a lot of stuff dealing with
defining languages related to VLSI tools ... including starting out a
(mainframe) pascal language. the pascal language eventually evolved to
the point that it was released to customers as pascal/vs (and later also
released on aix).

pascal/vs was used to implement the mainframe tcp/ip stack ... which
suffered from none buffer overflow vulnerabilities and exploits
commoningly associated with C language implementations ... misc past
posts mentioning C language
http://www.garlic.com/~lynn/subintegrity.html#overflow

it wasn't so much that it was impossible to implement buffer overflow
problems in pascal ... it just was that it took enormous amount of
effort to have buffer overflows ... compareable to the effort in C
language environments to NOT having buffer overflows.

unrelated to the use of Pascal language in the mainframe tcp/ip stack
implementation ... here are various past references to doing
the rfc1044 implementation for the mainframe tcp/ip product ... and
in some tuning work at cray research getting something like 30 times
the thruput with 1/20 the pathlength (nearly 3 orders of magnitude
improvement)
http://www.garlic.com/~lynn/subnetwork.html#1044

in many ways, pascal shares the difficulty of having buffer overflowd
with the much more ungainly PLI ... slight drift here
about air force security study of "multics" (implemented in PLI)
including mentioning of not having any buffer overflows:
http://www.garlic.com/~lynn/2002l.html#42 Thirty Years Later: Lessons from the Multics Security Evaluation

somewhat more topic drift ... multics was going on the 5th
flr of 545 tech sq ... and the science center doing virtual machine
cp67 work was on 4th flr of 545 tech sq ... misc. past references
http://www.garlic.com/~lynn/subtopic.html#545tech

i was undergraduate at a univ. that had installed cp67 and I got to play
with it. the vendor even asked if i could make some specific
enhancements. in retrospect ... some of the enhancements may have
originated from these guys ... which I didn't learn about until much
later:
http://web.archive.org/web/20070305054431/http://www.nsa.gov/selinux/list-archive/0409/8362.cfm

for some turbo pascal (& c) trivia ... there was an effort a couple yrs
ago to recover several old borland turbo distribution diskettes (i had
to find a 5.25 floppy drive, i eventually managed to recover close to 30
floppies):
http://www.garlic.com/~lynn/2006s.html#35 Turbo C 1.5 (1987)
http://www.garlic.com/~lynn/2006s.html#37 Turbo C 1.5 (1987)

i had logitech modula2 diskettes but didn't try and recover them.

 

[Anne & Lynn Wheeler]

I loved having Pascal/VS available!

I used it once to write the mainframe part of a heavily customized
Kermit implementation that was capable of using 1900+ byte large
packets, by filling most of a screen image.

The client was on the other end of a 3270 protocol emulator, talking
VT100 or similar, and it would remove the screen formatting sequences
and end up with the same packet data.

The fun part was that this worked pretty much immediately, and ran just
as fast as the file transfer facility on a dedicated 3270-PC, and 10x
faster than the (Kermit) reference version which used the default single
line packets.

re:
http://www.garlic.com/~lynn/2009e.html#11 Lack of bit field instructions in x86 instruction set because of ?patents ?

not long after the "troubles" in '92 (went into the "red") ... the
company was spinning off and/or moving to COTS for some number of things
(lots of cost/capital reducing measures). some of this was moving to
outside vendor off-the-shelf electronic design tools ... which also
involved transferring some number of internal tools to outside
vendors.

we had already left ... but i got a consulting contract to port a >50k
statement (rs/6000) pascal/vs (electronic design) application to other
platforms (as part of outside vendor picking up the application).
pascal/vs had lots of enhancements and some number of other pascals
appeared to have been used for little more than student education
projects ... which significantly complicated the port (that plus one of
the vendors had outsourced their pascal to an organization 12 time-zones
away).

 

[Rich Grise]

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

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?

Thanks,
Rich