EDAboard.com | EDAboard.de | EDAboard.co.uk | WTWH Media

2066-pin processors

Ask a question - edaboard.com

elektroda.net NewsGroups Forum Index - Electronics Design - 2066-pin processors

Goto page Previous  1, 2, 3 ... 17, 18, 19, 20  Next

Phil Hobbs
Guest

Thu Jan 03, 2019 3:45 pm   



On 1/2/19 10:34 PM, Joseph Gwinn wrote:
Quote:
On Jan 2, 2019, 698839253X6D445TD_at_nospam.org wrote
(in article <q0igd0$1eqm$1_at_gioia.aioe.org>):

Joseph Gwinn wrote
On Jan 2, 2019, 698839253X6D445TD_at_nospam.org wrote
(in article <q0i10n$18ps$1_at_gioia.aioe.org>):

Joseph Gwinn wrote
An EMP pulse powerful enough to cripple a steel ship (despite HEMP
shielding)
would have also crippled the airplane. One cannot really point such
weapons,
and the airplane is far closer to the source than the ship.

I think you can.

How? Even very large antennas (measured in wavelengths) are not nearly
directive enough. Do some numbers.

Can you cite some reliable sources?



It would be a bit embarrassing if it was used.
US fleet loses its way all by itself,
and then there is that ego thing, listen to this sound track:
https://www.youtube.com/watch?v=3D3D76OlqSd_5k8

Really? To believe this, one must also believe that an entire multi-ship
Carrier Task Group completely lacks competent navigators, paper maps, GPS
receivers, sextants, eyeballs, and so on. Thousands of people who do this
fo

a living, and would like to continue to do so, and not one person noticed
the problem.

It is a true story, just a few years ago maybe up to one year ago many
collisions between US navy ships and commercial ships happened.

Cites to reliable sources?


Over here you need a license, exams, for any ship over 10 meters,
also for how to use communication, and navigation.

Same over here.


I actually have one of those.
This 'captain' (was he really the captain, looks like some deckhand at the
controls),
giving away military secrets on top, has no situational awareness,
he should be with his nose on the charts looking at depth,
AND know the names of the coastal stations and lighthouses.

If indeed he was in fact the or even a Captain, and that recording was not a
hoax.

The size and composition of a Carrier Task Group is not a secret. And how
could it be - it=B4s there for all to see.

When I first heard this story, it was an unspecified US Coast Guard
lighthouse and some random freighter. Even then, I wondered why the
lighthouse omitted a critical fact, that it was a dry-land lighthouse, and
not just another ship, holding this detail till last.

No, that is standard procedure, the name of the lighthouse is sufficient,
the captain should know where he is, and that lighthouse name is indicated
on
his charts,

Even so, one would think that people would have the judgement to realize
what=B4s happening and get to the point far sooner.


After all those recent collisions and that is really only the top of the
iceberg so to speak,
big changes were made in the navy command chain.
I am sure some captains / commanders were demoted, maybe to deckhand Wink.

The brain config
'we are the strongest and we do not give way' and total cluelessness as to
navigation and maritime rules
is a sign that also appears in the current leadership of the divided
states.

Certainly that recording plays directly to a common preconception. But the
question is not if personality disorders exist - they most certainly do -
but if this recording is a hoax.


This has been around
forever:<https://www.snopes.com/fact-check/the-obstinate-lighthouse/

Yes, and the same mistake is made again and again and again:
https://www.realcleardefense.com/articles/2018/05/21/us_naval_accidents_re
visted_113469.html
https://www.channelnewsasia.com/news/singapore/uss-mccain-us-navy-report-c
ollsions-basic-errors-fitzgerald-9366422
There is no doubt that the US Navy has accidents, especially when they allow
themselves to become lax, and the commanders are in fact cashiered for
allowing preventable accidents.

But the above URLs are irrelevant to our question, which is if the recording
about the Carrier Task Group getting into a tangle with an obstinate
lighthouse is a hoax.

Joe Gwinn

I am not authorized to answer some of these questions.

Then you’ve already said way too much.


As to the EMP case and I think this is common knowledge, remember
that any exposed piece of wire, including for lighting, on deck cables,
antennas, can easily conduct MV into the inside of a Faraday cage.
The rest left to the imagination.

All true. But it is a solved problem. There is a huge literature, all paid
for by the US DoD.

But expensive I’ll grant.

Maybe everything is a hoax and we live in the matrix...
But let it be a sign on the wall, warning.
Personally I doubt the value of the US navy, these days with underwater
nuclear drones that can be manufactured for a few k$, an enemy can disable US ports any time.

Where can one buy a nuclear weapon for a few K$? I want one.

Any major power can destroy a port. The problem is that the victim power will
return the favor, with interest.

US navy and army is a tax money sink.

True enough, ever since WW2, to be able to manhandle the Warsaw Pact.

Hmm. Why didn’t Stalin take the rest of Europe after WW2? He certainly
wanted it.


He didn't have nukes till '49, which was way too late.

BTW you're falling foul of the mud-wrestling rule. ;)

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Martin Brown
Guest

Thu Jan 03, 2019 3:45 pm   



On 02/01/2019 15:41, John Larkin wrote:
Quote:
On Wed, 2 Jan 2019 01:02:23 -0800 (PST), whit3rd <whit3rd_at_gmail.com
wrote:

On Tuesday, January 1, 2019 at 2:47:23 PM UTC-8, John Larkin wrote:
On Tue, 1 Jan 2019 23:30:55 +0100, David Brown
david.brown_at_hesbynett.no> wrote:

You don't know much about programming.

You don't seem to approve of memory management. You don't seem to
envision computer systems ever being reliable.

A general-purpose computer SHOULD be able to run an APL interpreter,
and execute data whenever the 'execute' character calls for it.
That's just a language element OF THE LANGUAGE, and
no OS or hardware that supports the language ought to
sabotage that function.


OTOH executing user code should never bring down the operating system.
APL was even more of a cryptic terse write only language than Forth.

Quote:
If 'reliability' were the only virtue of a computer, we'd still be using
slide rules (one moving part, no electricity).

The problem with the current generation computers and computing
languages is that reliability wasn't designed in from the start, and
it isn't a big part of the culture now either.


There were languages that were designed from the outset to be very high
reliability but they have never gained traction in the commercial sphere
where time to market is everything.
Quote:

Writing reliable code, and especially writing exploit-hardened code,
is so hard that few people do it.


Exploit hardened code is more expensive because you have to guard
against very creative exploits that may be far into the future. No one
foresaw the long term problems that would come from some of the clever
go faster stripes for caches put into modern CPUs until it was too late.

Quote:
Some day we'll have a fresh start, but too many people are enamored of
and invested in the current mess that they don't even want to think
about anything better. So it will probably happen bottom-up.


Don't hold your breath. New hardware paradigms intended for reliability
like the Transputer and Viper came and went - the latter amid much
acrimony. I don't doubt that eventually CPU cycles will be so cheap and
human cycles so expensive that using some of the tools already available
for static testing of data flow in code will become more common.

--
Regards,
Martin Brown

Phil Hobbs
Guest

Thu Jan 03, 2019 3:45 pm   



On 1/2/19 4:02 AM, whit3rd wrote:
Quote:
If 'reliability' were the only virtue of a computer, we'd still be using
slide rules (one moving part, no electricity).


If 'reliability' were the only virtue of a computer, we'd still be using
slide rules (one moving part, no electricity).

Two moving parts, unless your cursor fell off. Or maybe your slipstick
just needs lubrication. ;)

Cheers

Phil Hobbs


--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Tom Gardner
Guest

Thu Jan 03, 2019 3:45 pm   



On 03/01/19 14:30, Martin Brown wrote:
Quote:
On 02/01/2019 15:41, John Larkin wrote:
Some day we'll have a fresh start, but too many people are enamored of
and invested in the current mess that they don't even want to think
about anything better. So it will probably happen bottom-up.

Don't hold your breath. New hardware paradigms intended for reliability like the
Transputer and Viper came and went - the latter amid much acrimony.


The Transputer and Occam are alive and well in the *hard*[1]
realtime embedded arena with at least one of the original
team there (Prof David May).

They are now called xCORE and xC, from XMOS, have been
expanding since 2008, and can be bought at DigiKey.

As for Viper - they almost got it right, but a miss
is as good as a mile!

[1] IDE *guarantees* timing to the instruction level
(i.e. 10ns), by inspecting the (optimised) object code.
None of this "measure and hope we encountered the worst
case" nonsense Smile


Guest

Thu Jan 03, 2019 4:45 pm   



On Thu, 03 Jan 2019 07:51:24 -0500, Joseph Gwinn
<joegwinn_at_comcast.net> wrote:

Quote:
On Jan 3, 2019, upsidedown_at_downunder.com wrote
(in article<42rr2e5r4kn547dj0minkvb3kasfv0het2_at_4ax.com>):

On Thu, 3 Jan 2019 11:16:23 +0100, David Brown
david.brown_at_hesbynett.no> wrote:

On 03/01/2019 09:08, Tim Williams wrote:
"David Brown"<david.brown_at_hesbynett.no> wrote in message
news:q0j73s$jsf$1_at_dont-email.me...

Eliminate pointers. They are like giving babies loaded guns.

Eliminate babies (or at least don't let them check in code without
passing a review from more senior programmers).

Why not both?

Use a language that doesn't use pointers.

Well -- they all do, obviously, but you aren't allowed to do pointer
arithmetic, and unbounded accesses and checks. A Java array access (or
certain string operations) might be straightforward pointer arithmetic,
but you aren't allowed to do it that way. You can't cast any Object to
anything else, and read that memory as an illegal object (pattern of
elements in memory).

It can often be a good idea to use raw pointers as rarely as possible -
and to tie them down when you can. (For example, use pointer-to-const,
put your arrays inside a struct, make access functions - anything that
helps the compiler spot errors in the code.)

If you are using a language that supports more controlled access, such
as C++ references, containers, smart pointers, etc., then these are
usually a better choice.

But deep down, at the lowest level, you need to use pointers. If your
language won't give you pointers, you are not going to get the most
efficient code. That might be a fair tradeoff for most code, but not
for everything.

Most of old commercial and scientific code is written in languages
that did not support pointers.

However, for instance in Fortran, you could pass multidimensional
arrays of different sizes to a library subroutine, so not so much need
for pointers. Of course, the pass-by-reference parameter passing could
be abused to do some pointer like tricks Smile.

Aside from implementation of algorithms that require pointers, the big
problem with Fortran was that it had no way to address something that it did
not create and name, which made control of hardware difficult, because I/O
registers appear in the memory space, looking like memory. No way to make
Fortran recognize this, or to pass a pointer in. Nor could Fortran handle
bitwise access all that well, or understand Volatile. There were many
workarounds, coded mostly in assembly, and later in C.


Memory mapped I/O was not a problem, at least on PDP-11.

Just create a named COMMON area with 4096 INTEGER*2 variables, each
representing an internal CPU register or UNIBUS peripheral register.
The named COMMON creates a named program section, use the linker to
base it at 160000 (octal) to the I/O page.

For a processor without memory management, that is all you have to do.
Access a UNIBUS card register is as reading or writing an integer
variable. When memory management was used, the task must be made
privileged, to map the top 4 KiW of 18/22 bit physical memory into the
top 4 KiW of 16 bit user address space.

As for volatility, use a separate compiled function to copy a value
from the common area (I/O page) since separate compilation would break
any optimization.

The problem with high level languages of the time was that they were
not fully re-entrant, e.g. for handling ISRs.

Long before C, BLISS https://en.wikipedia.org/wiki/BLISS was used as a
system programming language.

Quote:
Ada was also hopeless for hardware control, and so inherited the same kind of
workarounds, which for political reasons had to be in assembly - C was
anathema.


There were no political reasons, the problem as simply bad reentrancy
of old compilers. I remember one Pascal compiler for 6809, which had
'display' registers and the run time library was not re-entrant, so
usable only in the null task (user interface) in a RTOS. Using that
Pascal for ISR was completely unthinkable.

Phil Hobbs
Guest

Thu Jan 03, 2019 4:45 pm   



On 1/3/19 9:30 AM, Martin Brown wrote:
Quote:
On 02/01/2019 15:41, John Larkin wrote:
On Wed, 2 Jan 2019 01:02:23 -0800 (PST), whit3rd <whit3rd_at_gmail.com
wrote:

On Tuesday, January 1, 2019 at 2:47:23 PM UTC-8, John Larkin wrote:
On Tue, 1 Jan 2019 23:30:55 +0100, David Brown
david.brown_at_hesbynett.no> wrote:

You don't know much about programming.

You don't seem to approve of memory management. You don't seem to
envision computer systems ever being reliable.

A general-purpose computer SHOULD be able to run an APL interpreter,
and execute data whenever the 'execute' character calls for it.
That's just a language element OF THE LANGUAGE, and
no OS or hardware that supports the language ought to
sabotage that function.

OTOH executing user code should never bring down the operating system.
APL was even more of a cryptic terse write only language than Forth.


Plus you need a special keyboard, which is why I never got into APL
despite there being a strong APL subculture at IBM Watson.

It's pretty amazing though--it sticks bloody-mindedly to lazy
evaluation. That's magic.(*) An elevator controller running APL can
(apparently) invert a 1000x1000 matrix instantaneously. It just
computes the elements you actually use.

Cheers

Phil Hobbs

(*) R. Kipling, 'How the Rhinoceros Got His Skin', from "Just So
Stories". Describing the Parsee's cake: "It was indeed a Superior
Comestible (that's magic)."

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Martin Brown
Guest

Thu Jan 03, 2019 7:45 pm   



On 02/01/2019 17:51, John Larkin wrote:
Quote:
On Wed, 2 Jan 2019 18:27:39 +0100, David Brown
david.brown_at_hesbynett.no> wrote:

Within a very limited context, it is possible to make a design that is
bug-free. And that is fine - that should be your target when you are at
that stage. A VHDL/Verlilog module, or a C file, can be written without
bugs. At that level, you have complete control of the system and it
lives in an ideal world - there are no cosmic rays causing hiccups in
the system, no glitches in the power, no unexpected inputs, no stray
pointers in other code that trashes your data.

Eliminate pointers. They are like giving babies loaded guns.


They are far too useful to eliminate completely. Do you really want to
pass everything by value - even huge multidimensional arrays?

If you allow array descriptors which include a hard maximum bound then
code can be made a lot safer. But there are always ways and means to
subvert the system - usually where input output is concerned.

Languages that enforce absolute strict variable typing have to provide
an input and an output method for each and every type. It can get clumsy
and very hard to read even if the intention is to make it clearer!

Quote:
As the system complexity increases, however, it becomes harder and
harder to keep such guarantees of perfection. It must then be balanced
against the costs of the system - no one wants a perfect product if the
development costs are sky-high and the release time is next to eternity.
(At the highest levels of software quality, for the most safety
critical systems, productivity for a programmer might be half a dozen
lines of code in per week. Are you willing to pay that cost?)

What /I/ would like to see is less ambitious, and more realistic - I
would like to see more effort put into quality, and I would like to see
people being willing to accept higher prices and longer development
times to achieve that. I want progress - I want things to be better. I
don't want to waste time and money pointlessly chasing a mythical
"perfection". Can you understand that?


There are quite a few static analysis tools that could go a long way to
catching many of the sorts of mistakes that human programmers make - but
sadly they are not often used Sad People always look hurt when I run such
tools against a supposedly working codebase and find things wrong.

Quote:
If the OS and compilers were properly designed, programmers would of
course still write stupid code that was full of bugs, but they
couldn't create security risks if they wanted to.


And if pigs had wings they could fly. Compilers these days are quite
remarkable in terms of how well they can optimise code for a given
architecture. They do it so well that only a small number of experts can
beat them now - especially if you have profile directed optimisation.

Quote:
How much time and money are wasted on AV software and recovering from
hostile exploits? On IT security consultants?


There will always be hostile exploits across the boundaries of software
and external data. Even essential components of an normal operating
system can be used to wreck it. The program that starts two copies of
itself being a classic example, another which would arise with
monotonous regularity every year is some naive user tries to transpose a
large matrix bringing the OS to a standstill with page faults.

Quote:
Some university should specialize in designing and teaching software
design for reliability. I know a CS dean, and she's not interested in
trivial problems like that.


Some universities do that. My university degree emphasised provably
correct software development. But I understand that while such code may
be bug-free, it is only part of a more complete system.

Provable correctness was a fad for a while, but seems to have died
out. Programming itself is not of interest (and is in fact insulting)
to many CS departments.


Provable correctness is still used in places where it really matters. I
was a fan of Z and VDM for a while. But the level of mathematics needed
makes it hard to train people to use it. ETH Zurich computer science
department had some very good stuff from the Wirth stable of languages
including a very early circuit design computer well ahead of its time.

> My concern isn't correctness, but security.

They tend to go together. Badly engineered software will tend to fail in
unpredictable ways and some of those can be exploited. Bits of the
project still live on in another guise.

http://www.sysecol2.ethz.ch/RAMSES/MacMETH.html

Amusing fact - Logitech of mouse fame started out as a reseller of the
IBM PC port of ETH Zurich's Modula 2 compiler.

--
Regards,
Martin Brown


Guest

Thu Jan 03, 2019 9:45 pm   



Cursitor Doom wrote
Quote:
On Tue, 01 Jan 2019 17:49:30 +0000, 698839253X6D445TD wrote:

Oh and K&R as pdf

If you're talking about The C Programming Language, then I have the hard
copy. It's truly remarkable, the precision and clarity with which it has
been written. Absolutely outstanding. Shame all reference books aren't in
that class.


I had the hard copy, but it got wet...

If you use Linux, libc.info is a must.
I could not have written all the stuff I did without it.
One my system it is here
/usr/info/libc.info.gz
/usr/info/libc.info-1.gz
.....
/usr/info/libc.info-10.gz
/usr/info/libc.info-11.gz


I unzipped all files and concatenated (cat remember) all together
into on long libc.info ASCII file.
This one is 69804 lines long.

Use search in your editor (I use 'joe' as editor in Linux)
for any subject regarding library functions you like.
It has clear examples too.

There is everything from networking to memory to files to whatever,
math functions...
Here is a very old version from 1999 on my site:
http://panteltje.com/pub/libc.info.txt

If you know all that you are good to go for most projects.
I still use it frequently.

Gerhard Hoffmann
Guest

Thu Jan 03, 2019 9:45 pm   



Am 03.01.19 um 12:10 schrieb upsidedown_at_downunder.com:
Quote:
On Thu, 3 Jan 2019 11:16:23 +0100, David Brown


Quote:
But deep down, at the lowest level, you need to use pointers. If your
language won't give you pointers, you are not going to get the most
efficient code. That might be a fair tradeoff for most code, but not
for everything.

Most of old commercial and scientific code is written in languages
that did not support pointers.

However, for instance in Fortran, you could pass multidimensional
arrays of different sizes to a library subroutine, so not so much need
for pointers. Of course, the pass-by-reference parameter passing could
be abused to do some pointer like tricks Smile.


Who needs pointers when you've got integers?

Have you seen the memory management in Fortran as done
in Spice 2? Happily indexing across the bounds of a
not-really-existing-this-way array?

The wonders of EQUIVALENCE statements?

cheers,
Gerhard

Warning: The text above may contain traces of sarcasm.

Tim Williams
Guest

Thu Jan 03, 2019 10:45 pm   



<upsidedown_at_downunder.com> wrote in message
news:inss2elqrtjg6926to554rt5rlsob9vtpm_at_4ax.com...
Quote:
What is wrong with that or C language union statement ?

Very handy e.g. for extracting the binary exponent of a float to
determine the approximate size of a float.


And thus we come to mention the "WTF?" constant.

Made famous in John Carmack's Quake 3 source code, as a fast inverse square
root is used to calculate draw distance. Arithmetic operations, and a bit
of floating point abuse, saved many cycles over doing it the canonical (more
accurate) way.
https://en.wikipedia.org/wiki/Fast_inverse_square_root

Tim

--
Seven Transistor Labs, LLC
Electrical Engineering Consultation and Design
Website: https://www.seventransistorlabs.com/


Guest

Thu Jan 03, 2019 10:45 pm   



On Thu, 3 Jan 2019 21:18:52 +0100, Gerhard Hoffmann
<ghf_at_hoffmann-hochfrequenz.de> wrote:

Quote:
Am 03.01.19 um 12:10 schrieb upsidedown_at_downunder.com:
On Thu, 3 Jan 2019 11:16:23 +0100, David Brown


But deep down, at the lowest level, you need to use pointers. If your
language won't give you pointers, you are not going to get the most
efficient code. That might be a fair tradeoff for most code, but not
for everything.

Most of old commercial and scientific code is written in languages
that did not support pointers.

However, for instance in Fortran, you could pass multidimensional
arrays of different sizes to a library subroutine, so not so much need
for pointers. Of course, the pass-by-reference parameter passing could
be abused to do some pointer like tricks Smile.


Who needs pointers when you've got integers?


Who needs types ? A register is a nice place for storing integers or
addresses or a few characters.

Quote:
Have you seen the memory management in Fortran as done
in Spice 2? Happily indexing across the bounds of a
not-really-existing-this-way array?

The wonders of EQUIVALENCE statements?


What is wrong with that or C language union statement ?

Very handy e.g. for extracting the binary exponent of a float to
determine the approximate size of a float.

Quote:

cheers,
Gerhard

Warning: The text above may contain traces of sarcasm.


+1

whit3rd
Guest

Thu Jan 03, 2019 11:45 pm   



On Thursday, January 3, 2019 at 6:14:16 AM UTC-8, Phil Hobbs wrote:
Quote:
On 1/2/19 4:02 AM, whit3rd wrote:
If 'reliability' were the only virtue of a computer, we'd still be using
slide rules (one moving part, no electricity).

If 'reliability' were the only virtue of a computer, we'd still be using
slide rules (one moving part, no electricity).

Two moving parts, unless your cursor fell off. Or maybe your slipstick
just needs lubrication. Wink


The prototypical slide rule (Napier's bones) didn't have the cursor, but
I take your meaning. One of my collection of slipsticks has a broken cursor,
it's HARD to build one; thin glass from a craft-shop mirror, diamond blade to
cut it (too small for scribe/snap), and I'm still not sure how to make that
little groove and fill it with paint. Copper wheel and abrasive, maybe?

whit3rd
Guest

Thu Jan 03, 2019 11:45 pm   



On Thursday, January 3, 2019 at 4:51:32 AM UTC-8, Joseph Gwinn wrote:

Quote:
Aside from implementation of algorithms that require pointers, the big
problem with Fortran was that it had no way to address something that it did
not create and name


Well, maybe not directly, but shared libraries, virtual memory and other
understructure can have the same effect when it's useful. In VMS,
there were lots of cross-language subroutine calls, and very useful ones,
because the languages had a LOT in common, courtesy of good
OS support.


Guest

Thu Jan 03, 2019 11:45 pm   



On Thu, 3 Jan 2019 14:18:31 -0800 (PST), whit3rd <whit3rd_at_gmail.com>
wrote:

Quote:
On Thursday, January 3, 2019 at 4:51:32 AM UTC-8, Joseph Gwinn wrote:

Aside from implementation of algorithms that require pointers, the big
problem with Fortran was that it had no way to address something that it did
not create and name

Well, maybe not directly, but shared libraries, virtual memory and other
understructure can have the same effect when it's useful. In VMS,
there were lots of cross-language subroutine calls, and very useful ones,
because the languages had a LOT in common, courtesy of good
OS support.


In VAX/VMS each language was require the hardware defined subroutine
call instruction that defined the stack frame etc. Hence you could
programming languages in a program quite freely. The run time library
(RTL) also contained a lot of useful functions callable from any
language.

Once a customer demanded that a data security program to be written in
Cobol. No problem handling access control lists (ACL) and protection
bitmask. and other system programming things. That Cobol program
consisted mostly on RTL calls Smile.

Phil Hobbs
Guest

Fri Jan 04, 2019 12:45 am   



On 1/3/19 1:10 PM, Martin Brown wrote:
Quote:

There are quite a few static analysis tools that could go a long way to
catching many of the sorts of mistakes that human programmers make - but
sadly they are not often used Sad People always look hurt when I run such
tools against a supposedly working codebase and find things wrong.


I used to use PC-Lint, but my most recent version is C++98. ;)

What are your faves?

Cheers

Phil Hobbs

--
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

Goto page Previous  1, 2, 3 ... 17, 18, 19, 20  Next

elektroda.net NewsGroups Forum Index - Electronics Design - 2066-pin processors

Ask a question - edaboard.com

Arabic version Bulgarian version Catalan version Czech version Danish version German version Greek version English version Spanish version Finnish version French version Hindi version Croatian version Indonesian version Italian version Hebrew version Japanese version Korean version Lithuanian version Latvian version Dutch version Norwegian version Polish version Portuguese version Romanian version Russian version Slovak version Slovenian version Serbian version Swedish version Tagalog version Ukrainian version Vietnamese version Chinese version Turkish version
EDAboard.com map