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 ... , 18, 19, 20  Next

Gerhard Hoffmann
Guest

Fri Jan 04, 2019 1:45 am   



Am 04.01.19 um 00:14 schrieb Phil Hobbs:
Quote:
On 1/3/19 1:10 PM, Martin Brown wrote:

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?


We used Coverity when I was with Verigy, very efficient and worth the money.

Quote:
Cheers
Gerhard


Phil Hobbs
Guest

Fri Jan 04, 2019 2:45 am   



On 12/28/18 11:10 AM, Tom Gardner wrote:
Quote:
On 28/12/18 01:12, Phil Hobbs wrote:
On 12/27/18 6:48 PM, Clifford Heath wrote:
On 28/12/18 6:54 am, John Larkin wrote:
On Thu, 27 Dec 2018 12:56:52 +0100, David Brown
david.brown_at_hesbynett.no> wrote:
On 26/12/18 19:37, John Larkin wrote:
Please name one secure embedded OS.
I wrote a few, but they are not publicly available.
No, you did not.  If you think you did, you don't know what
"secure" means.
We usually run bare-metal in embedded systems, with our own tcp/ip
stack, and a state-machine based task manager. That's secure.
No, it is not secure.

I can quite believe that you (or your company) have written software
that is very secure, and for which there has never been a known
security
breach.

But security is never absolute.

Disagree. It's possible to design a system that's connected to the
internet and absolutely can't be hacked. We do that all the time.
...> We had one product recently that could be crashed by massively
overflowing a serial-input buffer, but all it does is crash. It's
fixed.

I think that is a wild claim without backing - especially as
"insecure"
is as meaningless as "secure".

If both terms are meaningless, we may as well run Windows XP.

"Secure" means "always meets its guarantees".

To you.  To me, 'secure' has a range of meanings depending on the circs.

"In managing the DoD there are many unexpected
communications problems. For instance, when the
Marines are ordered to "secure a building," they
form a landing party and assault it. On the other
hand, the same instructions will lead the Army
to occupy the building with a troop of infantry,
and the Navy will characteristically respond by
sending a yeoman to assure that the building
lights are turned out. When the Air Force acts
on these instructions, what results is a three
year lease with option to purchase."

-- James Schlesinger (former Secretary of Defense, USA).


Fun.

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

Joseph Gwinn
Guest

Fri Jan 04, 2019 4:45 am   



On Jan 3, 2019, whit3rd wrote
(in article<9a4e0dad-84c4-4c11-9152-97c5f94e19f9_at_googlegroups.com>):

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.


Yes. VMS had a common function/subroutine interface, used for all languages.
It was far ahead of its time.

But for assembly, one just implemented that standard directly. Never had a
problem.

Joe Gwinn

Joseph Gwinn
Guest

Fri Jan 04, 2019 4:45 am   



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

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

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.


All true, but not for the platforms I was using, for reasons that I no longer
recall. We did use COMMON a lot. But reverting to assembly was usually easier
for the other problems. Its very easy to write an assembly-coded Fortran
function or subroutine.

The other problem with Ada was that it was obligate synchronous, so didnt
handle realtime I/O very well, where one cannot predict the order in advance,
and so must be able to dance to the events as they arrive.

Quote:

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


That actually didnt much matter. We had ISRs written in Fortran circa
1980. No stack back then. The ISR code had to be in a different process than
the application code, or they would overlay return pointers with each other's
return pointers. System would run for maybe ten minutes, then bang - all the
red lights came on. It was about 40,000 lines of Fortran, too much to attempt
debugging by code review.

I was brought in from a different project - fresh eyes. Spent a week figuring
this out, largely spent asking questions looking for the slipped assumption.
Which was basically that the application programmers did not know how
subroutines worked, and ended up sharing a common runtime utility function,
that converted from float to integer or the like, but had a name that was not
itself valid in Fortran code, and could only be used by generated code
calling utilities. It was this utility routines return address that was
overlaid with the wrong return address.
Quote:

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

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.


Nah. The political problem with C was that C and Ada83 were direct
competitors in the language wars. The Ada folk did not feel threatened by
assembly code, but C was their main threat. It didnt help that Ada was in
the process of losing the war to C. Ada95 came out long after the war was
lost. Now, C/C++ dominates, and Ada95 is a niche language used almost
entirely for DO-178-level safety critical code.

Joe Gwinn

Phil Hobbs
Guest

Sat Jan 05, 2019 4:45 am   



On 1/3/19 10:28 PM, Joseph Gwinn wrote:
Quote:
On Jan 3, 2019, whit3rd wrote
(in article<9a4e0dad-84c4-4c11-9152-97c5f94e19f9_at_googlegroups.com>):

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.

Yes. VMS had a common function/subroutine interface, used for all languages.
It was far ahead of its time.

But for assembly, one just implemented that standard directly. Never had a
problem.

Joe Gwinn

Or one could just compile an empty function into assembly, and hack that
up manually.

In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)

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

Gerhard Hoffmann
Guest

Sat Jan 05, 2019 5:45 am   



Am 05.01.19 um 04:12 schrieb Phil Hobbs:

Quote:
In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)

I have a nice HP41 app for my Android cell phone.
Google for Go41C.

Cheers, Gerhard

Martin Brown
Guest

Sat Jan 05, 2019 10:45 am   



On 02/01/2019 19:05, Cursitor Doom wrote:
Quote:
On Wed, 02 Jan 2019 09:41:57 +0000, 698839253X6D445TD wrote:

[...]

Thanks, Jan. I use a similar dodge myself when bugs arise. Great minds
think alike! Smile


You are stuck in the stone age before the invention of the wheel.

--
Regards,
Martin Brown

Jan Panteltje
Guest

Sat Jan 05, 2019 10:45 am   



On a sunny day (Sat, 5 Jan 2019 09:33:21 +0000) it happened Martin Brown
<'''newspam'''@nezumi.demon.co.uk> wrote in <q0ptl7$1knr$1_at_gioia.aioe.org>:

Quote:
On 02/01/2019 19:05, Cursitor Doom wrote:
On Wed, 02 Jan 2019 09:41:57 +0000, 698839253X6D445TD wrote:

[...]

Thanks, Jan. I use a similar dodge myself when bugs arise. Great minds
think alike! :-)

You are stuck in the stone age before the invention of the wheel.


I write code after code that works without all your so called problems,
show me yours.

You have no code and you have no tronics, what are you doing here?
Spammer.

Phil Hobbs
Guest

Sat Jan 05, 2019 12:45 pm   



On 1/4/19 11:34 PM, Gerhard Hoffmann wrote:
Quote:
Am 05.01.19 um 04:12 schrieb Phil Hobbs:

In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)

I have a nice HP41 app for my Android cell phone.
Google for Go41C.

Cheers, Gerhard


If I were prepared to run Android, that might be useful. ;)

Cheers

Phil Hobbs

(Blackberry 10 diehard, for data security reasons)

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

David Brown
Guest

Sat Jan 05, 2019 1:45 pm   



On 05/01/2019 10:33, Martin Brown wrote:
Quote:
On 02/01/2019 19:05, Cursitor Doom wrote:
On Wed, 02 Jan 2019 09:41:57 +0000, 698839253X6D445TD wrote:

[...]

Thanks, Jan. I use a similar dodge myself when bugs arise. Great minds
think alike! :-)

You are stuck in the stone age before the invention of the wheel.


That was my impression when I saw his code.

It was nothing to do with the debugging techniques. Printf / serial
port debugging outputs are often useful as a complement to a normal
debugger - gdb gives you a lot more power and flexibility for debugging,
but has the disadvantage of usually requiring you to pause the program
during debugging. There is no single debugging technique that suits all
purposes - and no good developer would dismiss particular types out of hand.


No, my issue is with the code itself. Functions with half a dozen
parameters? Hugh swaths of local variables, all declared at the start
of functions? Identifier lengths at odds with their scopes? Maybe I am
being unfair to judge from a couple of snippets here, but this looks
like someone who learned their C coding some 25 or 30 years ago, without
learning about code and data structures, and has not learned more since
then.

John Larkin
Guest

Sat Jan 05, 2019 5:45 pm   



On Fri, 4 Jan 2019 22:12:28 -0500, Phil Hobbs
<pcdhSpamMeSenseless_at_electrooptical.net> wrote:

Quote:
On 1/3/19 10:28 PM, Joseph Gwinn wrote:
On Jan 3, 2019, whit3rd wrote
(in article<9a4e0dad-84c4-4c11-9152-97c5f94e19f9_at_googlegroups.com>):

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.

Yes. VMS had a common function/subroutine interface, used for all languages.
It was far ahead of its time.

But for assembly, one just implemented that standard directly. Never had a
problem.

Joe Gwinn

Or one could just compile an empty function into assembly, and hack that
up manually.

In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)


I programmed a steamship propulsion system (steam valve, turbines,
prop, hull mass) on an HP 9100 desktop calculator, and sold a couple
hundred million dollars worth of systems (for which I was paid $400 a
month at the time.)

I graduated to a PDP-8 running Focal, which was a lot better.

Most calcs are programmable now, but I never program them. It's more
sensible to write a PowerBasic program, which allows comments.

I have a bunch of HP 32SII's, which is a decent calculator. Almost as
good as the original HP35.


--

John Larkin Highland Technology, Inc

lunatic fringe electronics


Guest

Sat Jan 05, 2019 5:45 pm   



On Sat, 05 Jan 2019 08:01:34 -0800, John Larkin
<jjlarkin_at_highlandtechnology.com> wrote:

Quote:
On Fri, 4 Jan 2019 22:12:28 -0500, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

On 1/3/19 10:28 PM, Joseph Gwinn wrote:
On Jan 3, 2019, whit3rd wrote
(in article<9a4e0dad-84c4-4c11-9152-97c5f94e19f9_at_googlegroups.com>):

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.

Yes. VMS had a common function/subroutine interface, used for all languages.
It was far ahead of its time.

But for assembly, one just implemented that standard directly. Never had a
problem.

Joe Gwinn

Or one could just compile an empty function into assembly, and hack that
up manually.

In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)

I programmed a steamship propulsion system (steam valve, turbines,
prop, hull mass) on an HP 9100 desktop calculator, and sold a couple
hundred million dollars worth of systems (for which I was paid $400 a
month at the time.)

I graduated to a PDP-8 running Focal, which was a lot better.

Most calcs are programmable now, but I never program them. It's more
sensible to write a PowerBasic program, which allows comments.


For reusable calculations, like power system design, I use Excel
spreadsheets. The language sucks but the interface makes up for it. I
only need to write the "application" once and I can use it forever. In
fact several of the other engineers in the organization use my
spreadsheets and they're considered "best practices" in our
organization now.

Quote:
I have a bunch of HP 32SII's, which is a decent calculator. Almost as
good as the original HP35.


I have a 35S (whatever the "new" HP-35 is called). It sucks, compared
to the original and the '45 but at least it's RPN. I also bought a
mint condition 11C from eBay a couple of years ago. It's the best of
the HPs, IMO. I also have an 11C emulator on my Note-8 (and every
cell phone before) that's identical to the original.

Phil Hobbs
Guest

Sat Jan 05, 2019 5:45 pm   



On 1/5/19 11:01 AM, John Larkin wrote:
Quote:
On Fri, 4 Jan 2019 22:12:28 -0500, Phil Hobbs
pcdhSpamMeSenseless_at_electrooptical.net> wrote:

On 1/3/19 10:28 PM, Joseph Gwinn wrote:
On Jan 3, 2019, whit3rd wrote
(in article<9a4e0dad-84c4-4c11-9152-97c5f94e19f9_at_googlegroups.com>):

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.

Yes. VMS had a common function/subroutine interface, used for all languages.
It was far ahead of its time.

But for assembly, one just implemented that standard directly. Never had a
problem.

Joe Gwinn

Or one could just compile an empty function into assembly, and hack that
up manually.

In my late teens and early 20s I used to do a lot of HP calculator
programming, which was about as close to assembly language as I wanted
to get.

Cheers

Phil Hobbs

(Who still uses an HP 41CV a few times per week)

I programmed a steamship propulsion system (steam valve, turbines,
prop, hull mass) on an HP 9100 desktop calculator, and sold a couple
hundred million dollars worth of systems (for which I was paid $400 a
month at the time.)

I graduated to a PDP-8 running Focal, which was a lot better.

Most calcs are programmable now, but I never program them. It's more
sensible to write a PowerBasic program, which allows comments.

I have a bunch of HP 32SII's, which is a decent calculator. Almost as
good as the original HP35.



I mostly use an old version of Mathcad for that. It's a lot less work
than translating math into code. I also have a copy of Mathematica 8
that I've basically never used.

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

Gerhard Hoffmann
Guest

Sat Jan 05, 2019 7:45 pm   



Am 05.01.19 um 17:01 schrieb John Larkin:

Quote:

I have a bunch of HP 32SII's, which is a decent calculator. Almost as
good as the original HP35.


I still have an original HP35. That still should work if I could find
a battery pack. The father of a class mate who worked for BB&C
bought some for us because HP then had no consumer distributors.

Cheers, Gerhard

Tom Gardner
Guest

Sat Jan 05, 2019 9:45 pm   



On 05/01/19 18:25, Gerhard Hoffmann wrote:
Quote:
Am 05.01.19 um 17:01 schrieb John Larkin:


I have a bunch of HP 32SII's, which is a decent calculator. Almost as
good as the original HP35.

I still have an original HP35. That still should work if I could find
a battery pack. The father of a class mate who worked for BB&C
bought some for us because HP then had no consumer distributors.


They work without the battery; the mains charger is sufficient.

You can get batteries here:
https://www.ebay.co.uk/sch/waterhosko/m.html

Goto page Previous  1, 2, 3 ... , 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