Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.arch.embedded > #12706 > unrolled thread
| Started by | Don Y <this@isnotme.com> |
|---|---|
| First post | 2013-07-25 12:23 -0700 |
| Last post | 2013-08-02 07:26 -0700 |
| Articles | 20 on this page of 118 — 12 participants |
Back to article view | Back to comp.arch.embedded
Resource revocation Don Y <this@isnotme.com> - 2013-07-25 12:23 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 12:51 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 15:00 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 19:38 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-25 23:37 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 01:13 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 02:48 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 04:19 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 09:46 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 10:21 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:30 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 11:56 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 20:08 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:11 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 12:31 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 11:08 -0700
Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 09:16 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 10:22 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:22 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 08:56 -0700
Re: Resource revocation Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-26 19:25 +0200
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 10:51 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:21 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-26 11:50 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 19:42 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:43 -0700
Does the Buddha have a real time nature? ;) (was Resource revocation) Roberto Waltman <usenet@rwaltman.com> - 2013-07-26 17:06 -0400
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-26 17:12 -0700
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:44 +0100
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 09:45 +0100
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Don Y <this@isnotme.com> - 2013-07-27 12:28 -0700
Re: Does the Buddha have a real time nature? ;) (was Resource revocation) Hans-Bernhard Bröker <HBBroeker@t-online.de> - 2013-07-27 14:11 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:40 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 21:29 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 13:52 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-26 22:55 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 17:22 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 10:02 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 09:29 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 18:20 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 12:48 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:57 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:18 -0700
Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:33 -0400
Re: Resource revocation upsidedown@downunder.com - 2013-07-27 22:53 +0300
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 22:42 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:41 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-27 16:49 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-28 08:39 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 23:11 -0700
Re: Resource revocation Roberto Waltman <usenet@rwaltman.com> - 2013-07-31 16:15 -0400
Re: Resource revocation upsidedown@downunder.com - 2013-08-01 00:13 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:16 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:05 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:37 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:38 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 16:08 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-28 01:16 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 18:43 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-28 09:01 +0300
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-27 15:21 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-27 23:07 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-26 12:00 -0700
Re: Resource revocation stephenXXX@mpeforth.com (Stephen Pelc) - 2013-07-27 16:49 +0000
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 18:31 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 15:51 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-28 20:12 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-28 18:35 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-29 00:10 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:23 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 01:05 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 12:07 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 01:11 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 15:20 -0700
Re: Resource revocation Rob Gaddi <rgaddi@technologyhighland.invalid> - 2013-07-29 15:42 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 16:41 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 08:51 +0300
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 09:09 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:30 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 10:04 +0100
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:55 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:12 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 16:59 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 13:17 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 10:12 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-30 18:48 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 20:18 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-31 09:27 +0300
Re: Resource revocation [long] Don Y <this@isnotme.com> - 2013-07-31 00:47 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-30 02:50 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-30 13:22 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 07:24 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 01:17 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-29 19:28 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-07-29 11:40 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 11:44 -0700
Re: Resource revocation Tom Gardner <spamjunk@blueyonder.co.uk> - 2013-07-29 20:56 +0100
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 13:16 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-30 00:08 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-30 23:41 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 00:58 -0700
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-31 10:18 -0700
Re: Resource revocation George Neuner <gneuner2@comcast.net> - 2013-08-02 06:19 -0400
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-08-03 02:26 -0400
Re: Resource revocation Paul Rubin <no.email@nospam.invalid> - 2013-07-28 19:31 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-29 00:44 -0700
Re: Resource revocation Richard Damon <Richard@Damon-Family.org> - 2013-07-25 22:42 -0400
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-25 22:12 -0700
Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-07-31 13:41 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 07:51 -0700
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 08:07 -0700
Re: Resource revocation Anders.Montonen@kapsi.spam.stop.fi.invalid - 2013-07-31 15:55 +0000
Re: Resource revocation Don Y <this@isnotme.com> - 2013-07-31 10:18 -0700
Re: Resource revocation "Boudewijn Dijkstra" <sp4mtr4p.boudewijn@indes.com> - 2013-08-01 14:42 +0200
Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-01 14:34 -0700
Re: Resource revocation upsidedown@downunder.com - 2013-08-02 09:08 +0300
Re: Resource revocation Don Y <this@isnotme.com> - 2013-08-02 07:26 -0700
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 18:20 +0100 |
| Message-ID | <jjTIt.17124$GQ5.12141@fx22.am4> |
| In reply to | #12763 |
On 27/07/13 17:29, Don Y wrote: > Hi Tom, >> >> Two reasons: >> - "those that can do, those that can't" teach >> the next generation > > Actually, I was fortunate to have reasonably good instructors. > But, I think it was a different era -- where you had to exert more > discipline over your "art" than the current reliance on automated > tools, "fleshy" languages, bloated libraries, etc. Oh, but "the library [or worse, framework] takes care of all of that for us". Including solving the byzantine generals' problem - I think not. :( >> - as employment expands and becomes "old hat", the >> brightest minds no longer go into the field and >> the top 1% are replaced by the top 10% > > Yes. And employers look to find ways to "dumb down" the > requirements for the folks they "need" in those positions. > Software bloat, hardware overkill, etc. Makes you wonder > what will happen when we eventually *do* hit a limit and > suddenly have to relearn Ye Olde Ways to make continued > advances! :< (hopefully, that'll be past *my* time! :> ) It has been pushed back for a *few* years by the cheap implementation of multicore processors. But that fails for more than a few cores due to inescapable memory bandwidth and latency ans coherence problems. Long term I think it will have to go down the non-coherent memory plus message passing route. >> If I was starting out again, I'd go into synthetic >> biology. > > <frown> I like mechanisms. (I guess you can argue that creating > an organic mechanism would be comparable). Hence, I am not usually > interested in "desktop software": > > "Oooooh! Look! I made it blink!" > "BFD. Watch me cut a pentagonal hole in this piece of steel...". Wow, I made something that'll outlast the human species :) or :( >>> I see this in lots of places. Folklore displacing science. >>> (e.g., don't use dynamic memory allocation; don't use recursion; >>> etc.) >> >> The "correct reason" for avoiding malloc and >> recursion is to enable the possibility of >> correctness proofs. But you know that. > > Actually, I think more often it is just fear of "common" bugs. > (then why not learn how to use these things more effectively?) > > I happen to be a huge fan of recursion as it makes so many > algorithms *so* much easier to implement correctly, out-of-the-box > *and* easier to understand (i.e., the equivalent iterative solutions > always look like there is a lot of housekeeping going on *in* the > code -- lots of opportunities for "little errors"). But, I'm also > careful to make sure something in the data implicitly controls the > depth of the recursion. > > For example, I use a recursive "matching" algorithm in one of my > TTS systems. But, rather than letting the "input" drive the > recursion, I let the *template* do so -- since I can ensure all > of the "const" templates have implied limits to the recursion > (but I can't make that same guarantee when processing arbitrary > "input") > > The malloc argument I think is just a failure of folks to think > about how memory is consumed in their application and, how the heap > is administered/implemented in their runtime. E.g., I can often > guarantee that malloc handles requests in *constant* time. So, > why *not* use it? Problems arise when the system has been designed and/or implemented by multiple companies/teams/people. Look at the problems inherent with using libraries in C++! (If C++ is the answer, I want to know what the question was!)
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 12:48 -0700 |
| Message-ID | <kt186a$r4p$1@speranza.aioe.org> |
| In reply to | #12765 |
Hi Tom,
On 7/27/2013 10:20 AM, Tom Gardner wrote:
>>> Two reasons:
>>> - "those that can do, those that can't" teach
>>> the next generation
>>
>> Actually, I was fortunate to have reasonably good instructors.
>> But, I think it was a different era -- where you had to exert more
>> discipline over your "art" than the current reliance on automated
>> tools, "fleshy" languages, bloated libraries, etc.
>
> Oh, but "the library [or worse, framework] takes care of all
> of that for us". Including solving the byzantine generals'
> problem - I think not. :(
And libraries never have bugs? (how many *digits* in a microsoft
release number??) :<
I think these "dumbing down" exercises suffer from the problem
of allowing developers to be ignorant of what's inside the box.
Even on a conceptual level!
One reason I enjoy writing in C so much is that I can get a
real feel for what resources are being used, how complex my
algorithm is, etc. Some of these other "languages" have
too much smoke and mirrors obfuscating what's going on at
the pins of the CPU!
>>> - as employment expands and becomes "old hat", the
>>> brightest minds no longer go into the field and
>>> the top 1% are replaced by the top 10%
>>
>> Yes. And employers look to find ways to "dumb down" the
>> requirements for the folks they "need" in those positions.
>> Software bloat, hardware overkill, etc. Makes you wonder
>> what will happen when we eventually *do* hit a limit and
>> suddenly have to relearn Ye Olde Ways to make continued
>> advances! :< (hopefully, that'll be past *my* time! :> )
>
> It has been pushed back for a *few* years by the cheap
> implementation of multicore processors. But that fails
> for more than a few cores due to inescapable memory
> bandwidth and latency ans coherence problems.
>
> Long term I think it will have to go down the non-coherent
> memory plus message passing route.
Yup. Hence my approach to distributing the automation system
(NoRMA, etc.). Of course, it's the sort of application (or,
"application set") that lends itself well to decomposition.
[Folklore, malloc, recursion, etc.]
> Problems arise when the system has been designed and/or
> implemented by multiple companies/teams/people.
*** AND POORLY DOCUMENTED! ***
Three of the big (huge!) problems I see with many FOSS projects
are:
- no "ownership" (no one takes responsibility for ensuring
the quality and consistency of the "product")
- no formal testing (where's the regression suite? Do you
expect every developer who touches the codebase to implement
his/her own test suite? Replicating the work of others?
Or, do *none* of them take on this task?? "Leave it to the
users to find the bugs!")
- no formal documentation (what is the product *supposed* to do?
Does anyone know? Or, is it "self-documenting": it does what
it does!)
PostgreSQL has been a refreshing defiance of these problems! :>
> Look at
> the problems inherent with using libraries in C++!
> (If C++ is the answer, I want to know what the question
> was!)
C++ was good for pushing the OOP paradigm into mainstream
thought. But, it tends to be too heavy-handed in how much
it does for (to?) you -- all the while claiming it is
making your life easier!
OTOH, it has made it much easier for folks examining my
(C) codebase to get used to the structure that I embed in
my data, "objects", etc. ("Why all these damn structs
all over the place???")
One cute feature I enjoy in Limbo is the use of "tuples".
So, I can make the return of sophisticated types and
pseudo types more obvious: [silly example]
(x, y, radius) := describe(a_circle)
is a bit more obvious than:
typedef struct {
point;
radius;
} circ_description;
typedef struct {
coord x;
coord y;
} point;
...
circ_description result;
...
result = describe(a_circle);
I.e., the original tuple example has implicit in that one
statement the declaration of the types of the returned
parameters -- as well as exposing those parameters to
the reader directly! (you don't have to chase down the
definitions of the "result")
(there are loads of things that I *don't* like in Limbo
so I revel in the few that I *do* like! :> )
--don
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 22:57 +0100 |
| Message-ID | <6nXIt.5183$et4.2314@fx09.am4> |
| In reply to | #12770 |
On 27/07/13 20:48, Don Y wrote:
> Hi Tom,
>
> On 7/27/2013 10:20 AM, Tom Gardner wrote:
>>>> Two reasons:
>>>> - "those that can do, those that can't" teach
>>>> the next generation
>>>
>>> Actually, I was fortunate to have reasonably good instructors.
>>> But, I think it was a different era -- where you had to exert more
>>> discipline over your "art" than the current reliance on automated
>>> tools, "fleshy" languages, bloated libraries, etc.
>>
>> Oh, but "the library [or worse, framework] takes care of all
>> of that for us". Including solving the byzantine generals'
>> problem - I think not. :(
>
> And libraries never have bugs?
Bugs can be removed. The byzantine generals (and
similar) problem provably cannot be removed.
> (how many *digits* in a microsoft
> release number??) :<
I don't care how many *builds* there are between releases.
> I think these "dumbing down" exercises suffer from the problem
> of allowing developers to be ignorant of what's inside the box.
> Even on a conceptual level!
>
> One reason I enjoy writing in C so much is that I can get a
> real feel for what resources are being used, how complex my
> algorithm is, etc. Some of these other "languages" have
> too much smoke and mirrors obfuscating what's going on at
> the pins of the CPU!
C is a mess even on uniprocessor machines. Multiprocessor
shared memory systems with caches make me shudder when
correctness is important. C++ is even worse.
>>>> - as employment expands and becomes "old hat", the
>>>> brightest minds no longer go into the field and
>>>> the top 1% are replaced by the top 10%
>>>
>>> Yes. And employers look to find ways to "dumb down" the
>>> requirements for the folks they "need" in those positions.
>>> Software bloat, hardware overkill, etc. Makes you wonder
>>> what will happen when we eventually *do* hit a limit and
>>> suddenly have to relearn Ye Olde Ways to make continued
>>> advances! :< (hopefully, that'll be past *my* time! :> )
>>
>> It has been pushed back for a *few* years by the cheap
>> implementation of multicore processors. But that fails
>> for more than a few cores due to inescapable memory
>> bandwidth and latency ans coherence problems.
>>
>> Long term I think it will have to go down the non-coherent
>> memory plus message passing route.
>
> Yup. Hence my approach to distributing the automation system
> (NoRMA, etc.). Of course, it's the sort of application (or,
> "application set") that lends itself well to decomposition.
>
> [Folklore, malloc, recursion, etc.]
>
>> Problems arise when the system has been designed and/or
>> implemented by multiple companies/teams/people.
>
> *** AND POORLY DOCUMENTED! ***
I've seen many systems which were "well documented"
but the documentation omitted to discuss key attributes,
probably because the architects didn't realise
there were underlying pitfalls!
> Three of the big (huge!) problems I see with many FOSS projects
> are:
> - no "ownership" (no one takes responsibility for ensuring
> the quality and consistency of the "product")
There's no improvement with proprietary systems. Every
study fails to show a consistent advantage to either
proprietary or FOSS products.
> - no formal testing (where's the regression suite? Do you
> expect every developer who touches the codebase to implement
> his/her own test suite? Replicating the work of others?
> Or, do *none* of them take on this task?? "Leave it to the
> users to find the bugs!")
Old engineering maxim: "you can't test quality into a product".
Hopefully you can design it in.
> - no formal documentation (what is the product *supposed* to do?
> Does anyone know? Or, is it "self-documenting": it does what
> it does!)
>
> PostgreSQL has been a refreshing defiance of these problems! :>
There are many examples of good and bad proprietary
and FOSS systems.
>> Look at
>> the problems inherent with using libraries in C++!
>> (If C++ is the answer, I want to know what the question
>> was!)
>
> C++ was good for pushing the OOP paradigm into mainstream
> thought.
No, it was a disaster.
Even the designers didn't know what they had created.
Classic case is that they were amazed when somebody
produced a valid C++ program that caused the compiler
to emit the sequence of prime numbers *during compilation*.
> But, it tends to be too heavy-handed in how much
> it does for (to?) you -- all the while claiming it is
> making your life easier!
Agreed.
> OTOH, it has made it much easier for folks examining my
> (C) codebase to get used to the structure that I embed in
> my data, "objects", etc. ("Why all these damn structs
> all over the place???")
Have a look at Nick MacLaren's "Objects Diatribe", and weep.
MacLaren has been on the sharp end of errant implementations
and the standardisation process for decades. He knows where
skeletons are buried.
> One cute feature I enjoy in Limbo is the use of "tuples".
> So, I can make the return of sophisticated types and
> pseudo types more obvious: [silly example]
> (x, y, radius) := describe(a_circle)
> is a bit more obvious than:
>
> typedef struct {
> point;
> radius;
> } circ_description;
>
> typedef struct {
> coord x;
> coord y;
> } point;
>
> ...
>
> circ_description result;
>
> ...
>
> result = describe(a_circle);
>
> I.e., the original tuple example has implicit in that one
> statement the declaration of the types of the returned
> parameters -- as well as exposing those parameters to
> the reader directly! (you don't have to chase down the
> definitions of the "result")
>
> (there are loads of things that I *don't* like in Limbo
> so I revel in the few that I *do* like! :> )
I don't know limbo, but if it is based on C then I
would need to be convinced that it has avoided C's
problems - and my remaining life is too short for
me to bother to look!
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 16:18 -0700 |
| Message-ID | <kt1kfc$p5k$1@speranza.aioe.org> |
| In reply to | #12773 |
Hi Tom,
On 7/27/2013 2:57 PM, Tom Gardner wrote:
[much elided]
>>> Problems arise when the system has been designed and/or
>>> implemented by multiple companies/teams/people.
>>
>> *** AND POORLY DOCUMENTED! ***
>
> I've seen many systems which were "well documented"
> but the documentation omitted to discuss key attributes,
> probably because the architects didn't realise
> there were underlying pitfalls!
Yup. Unfortunately, trying to merge documentation into
the source "product" just doesn't work. Forget LP and the
various nods to this effort (doxygen, etc.)
I've taken a more fundamental approach. I accompany my code
with "tutorials", of a sort. I.e., papers that present key
issues in a more conversational manner replete with illustrations,
etc. (currently trying to put interactive demos into them as
well!).
So, I don't have to explain *why* am am doing something in the code.
Just state *what* a particular piece of code is doing and leave
it to the reader to figure out "why this will work" by reading
the supporting tutorials.
A document that I always find "missing" is a roadmap (no, not
a description of the file hierarchy!): something that says
how the code moves from RESET through RUNTIME.
Finally, showing strong structure *in* the code so folks can
mimic this to cover all (most of) the bases when implementing
something similar (e.g., design of a multithreaded service).
Of course, people will *still* ignore all the above and complain
that "its a piece of crap". But, they'll only find agreement among
other "sloths". :>
>> Three of the big (huge!) problems I see with many FOSS projects
>> are:
>> - no "ownership" (no one takes responsibility for ensuring
>> the quality and consistency of the "product")
>
> There's no improvement with proprietary systems. Every
> study fails to show a consistent advantage to either
> proprietary or FOSS products.
I don't claim one camp is better than another. Rather, I am
commenting on what I see missing in SO MANY FOSS projects.
(i.e., people spend time on new features because they are
"more fun"... getting the *old* features to work properly
is boring! As will be getting the NEW features to work completely
NEXT WEEK!)
>> - no formal testing (where's the regression suite? Do you
>> expect every developer who touches the codebase to implement
>> his/her own test suite? Replicating the work of others?
>> Or, do *none* of them take on this task?? "Leave it to the
>> users to find the bugs!")
>
> Old engineering maxim: "you can't test quality into a product".
> Hopefully you can design it in.
You need a formal design and then a formal test plan to verify that
the implementation meets the design.
"Wow, Bill! What a great looking boat you built!"
"Um, I started out to build a doghouse..."
>> - no formal documentation (what is the product *supposed* to do?
>> Does anyone know? Or, is it "self-documenting": it does what
>> it does!)
>>
>> PostgreSQL has been a refreshing defiance of these problems! :>
>
> There are many examples of good and bad proprietary
> and FOSS systems.
Pgsql has been one of the few bright spots, for me. It
actually *feels* like someone is driving the process
instead of letting it wander off into featureland.
>>> Look at
>>> the problems inherent with using libraries in C++!
>>> (If C++ is the answer, I want to know what the question
>>> was!)
>>
>> C++ was good for pushing the OOP paradigm into mainstream
>> thought.
>
> No, it was a disaster.
You don't think C++ brought the idea of OOP into the mainstream?
Previously, folks were all writing procedural based implementations
and you had OOP left to languages like Smalltalk to propose.
[I'm not claiming it was a GOOD way for folks to embrace the
paradigm. Rather, that it brought it to the attention of a
generation of "programmers". E.g., after C++, I started
being far more consistent in how I structured my code
(regardless of implementation language) moving further
from the "A then B then C" approach to one where operations
and attributes were tied to "objects" (regardless of how I
implemented those objects)]
> Even the designers didn't know what they had created.
> Classic case is that they were amazed when somebody
> produced a valid C++ program that caused the compiler
> to emit the sequence of prime numbers *during compilation*.
>
>> But, it tends to be too heavy-handed in how much
>> it does for (to?) you -- all the while claiming it is
>> making your life easier!
>
> Agreed.
What I *liked* about C++ was how nicely I could combine
different types of numeric objects with infix notation
(and let the compiler sort out which casts to apply).
It gets tedious having to implement, e.g., a Rational
data type and do all operations as:
ratC = add(ratA, ratB);
ratG = mul(ratC, ratD);
ratF = exp(ratG, ratE);
double foo = realize(ratF);
E.g., I currently use a Q10.13 format in this project and
"expressions" using objects of this type don't lend themselves
freely to infix notation (other than addition of like types).
>> OTOH, it has made it much easier for folks examining my
>> (C) codebase to get used to the structure that I embed in
>> my data, "objects", etc. ("Why all these damn structs
>> all over the place???")
>
> Have a look at Nick MacLaren's "Objects Diatribe", and weep.
> MacLaren has been on the sharp end of errant implementations
> and the standardisation process for decades. He knows where
> skeletons are buried.
Historically, I'd been naive thinking standards were logically
reasoned. As I get older, I find it harder NOT to see the
"politics" (and economics) involved in many of these processes.
I'll search for a MacLaren reference...
>> (there are loads of things that I *don't* like in Limbo
>> so I revel in the few that I *do* like! :> )
>
> I don't know limbo, but if it is based on C then I
> would need to be convinced that it has avoided C's
> problems - and my remaining life is too short for
> me to bother to look!
It tries to clamp down on a lot of the freedom C affords
developers. With attempts to keep you from running with
scissors. (e.g., pointers are gone -- much to my dismay!)
As a general purpose language for general purpose problems,
I wouldn't recommend it. OTOH, as a scripting language
it seems to be expressive enough to address the sorts of
things that I want to be able to code (in this system).
Unfortunately, much of the implementation is devoid of
commentary. Its as if the developers feared their fingertips
would fall off after some fixed number of keystrokes and
tried to conserve them for "important stuff" :-(
And, of course, the documentation hasn't been updated since
the initial public offering.
<shrug> I suspect the principles are busy trying to keep
bread on their tables...
--don
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-07-31 16:33 -0400 |
| Message-ID | <hgsiv816fpk3m9c6tc8kitn9dgta3fehs6@4ax.com> |
| In reply to | #12773 |
Tom Gardner wrote: >Even the designers [of C++] didn't know what they had created. >Classic case is that they were amazed when somebody >produced a valid C++ program that caused the compiler >to emit the sequence of prime numbers *during compilation*. While at the same time discouraging the use of preprocessor macros ;) It is common knowledge that Stroustrup developed "C with classes"/C-front as a tool to work on simulation projects for which the Simula language would have been ideal, except for performance issues. But I never read anything referring, directly or indireclyt, to how/when the switch was made from "Let's make a tool to solve a problem" (or set of problems,) to "Let's make a general purpose programming language" If this had been the goal from the beginning, the language may have been quite different.
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-27 22:53 +0300 |
| Message-ID | <gb58v81h50vcd3sm1fr9dg07me7tfmkgiq@4ax.com> |
| In reply to | #12763 |
On Sat, 27 Jul 2013 09:29:11 -0700, Don Y <this@isnotme.com> wrote: >Hi Tom, > >On 7/27/2013 2:02 AM, Tom Gardner wrote: > >>>> SRT perf stats of the type I mentioned are common within >>>> the telecom industries, where performance, end-user >>>> irritation and, (in limiting pernicious cases) correctness >>>> are appropriately described by "mostly met" time intervals. >>> >>> Ah, makes sense. Yes, here telco services (at least LAND lines) >>> are regulated to the level of performance they must provide. >>> (I don't think there are any such guarantees for cellular >>> service?) And, this is evident in people's expectations >>> of that service! >> >> They may not be regulated, but internally inside networks >> the latency is still specified - and measured so that one >> subsystem supplier can push responsibility onto another >> supplier. > >Ah, OK. You are referring to networks in the more modern sense >(I was interpreting your comments in the classic telecom sense >of "PSTN") PSTN and ISDN are essentially circuit switched (or TDMA) with a guarantied throughput and constant latency. >> More importantly it is impossible to regulate the vagueries >> of the radio propagation channel. People often complain >> that multipath reception causes problems, but in mobile >> comms it is *required* in order to get reception in >> non-line-of-sight positions! > >Yup. But, here, there is a silent push for telecom providers >to move away from "wired land lines" as they are more costly (?) >to maintain *and* subject to stricter regulation on QoS than >wireless services. > >E.g., rather than replace existing/damaged land lines, providers >would like to provide residences with "immobile cellular stations" >that give them access to the wireless network at their "fixed" >home-line. Being downgraded from some ISDN 2B+D service to some packet switching system is definitely a loss. At least in Europe, service providers put 4 cellular phone links into a single 64 kbit/s B channel. Going from circuit switching to packet switching saves a lot for the service provider, when no capacity is needed, when the customer is "silent". >> The "correct reason" for avoiding malloc and >> recursion is to enable the possibility of >> correctness proofs. But you know that. <clip> >The malloc argument I think is just a failure of folks to think >about how memory is consumed in their application and, how the heap >is administered/implemented in their runtime. E.g., I can often >guarantee that malloc handles requests in *constant* time. So, >why *not* use it? I have absolutely nothing against using malloc(), but I definitely refuse to use free() in a critical industrial control system :-) :-). At least in industrial control systems the main reason for avoiding malloc is the dynamic memory pool fragmentation over decades of operation. Such systems are designed to work 10 (contractual requirement) to 50 years continuously without reboots. In many practical system, the next available boot time for clearing fragmented memory pool, might be possible at Feb 29th, 2016, when some big mechanical updates are done at the plant. At least that was the situation, when dedicated high reliability (and expensive) was used. Unfortunately these days, quite often some unreliable COTS hardware is used, forcing to use double or triple redundant systems. With a redundant system, rebooting a node is not a big difference, so memory leaking applications or memory pool fragmentation applications can be used. A redundant system makes it possible to hide some long time design bugs, which in the long run is a serious situation. > >> More subtly, interpreted = slow. To thoroughly confuse them, >> I point them to HP's Dynamo experience where an >> emulated processor running C outperforms the same >> non-emulated processor running optimised C (because >> the emulation enables the system to optimise the >> code that is actually executed, rather than the >> code that the compiler is forced to conservatively >> guess will be executed. > >Yup. Or, "hand optimized" is better than the compiler's >optimizer. Or, vice versa. Too much folklore and not >enough hard/empirical data! Yet, people rely on these >assumptions to make significant design decisions... :< While in the 1970's it was relatively easy to write an assembler program based on original specifications, trying to hand code some tested/working FORTRAN programs, I usually failed (speed/size). With current processors, the compilers will make a much better job. However in some rare cases, it is important to be able to tell what exact code (such as machine instruction) should be generated.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 22:42 +0100 |
| Message-ID | <T8XIt.17659$GQ5.13712@fx22.am4> |
| In reply to | #12771 |
On 27/07/13 20:53, upsidedown@downunder.com wrote: > On Sat, 27 Jul 2013 09:29:11 -0700, Don Y <this@isnotme.com> wrote: > >> E.g., rather than replace existing/damaged land lines, providers >> would like to provide residences with "immobile cellular stations" >> that give them access to the wireless network at their "fixed" >> home-line. > > Being downgraded from some ISDN 2B+D service to some packet switching > system is definitely a loss. > > At least in Europe, service providers put 4 cellular phone links into > a single 64 kbit/s B channel. > > Going from circuit switching to packet switching saves a lot for the > service provider, when no capacity is needed, when the customer is > "silent". That's true, but missing the point. POTS lines have availability guarantees backed by *statutes*. Cellular systems don't. > > >>> The "correct reason" for avoiding malloc and >>> recursion is to enable the possibility of >>> correctness proofs. But you know that. > > <clip> > >> The malloc argument I think is just a failure of folks to think >> about how memory is consumed in their application and, how the heap >> is administered/implemented in their runtime. E.g., I can often >> guarantee that malloc handles requests in *constant* time. So, >> why *not* use it? That guarantee does, of course, depend on the specific implementation of malloc. Some mallocs have suboptimum behaviour, particularly when they can't locate a suitable free block. > I have absolutely nothing against using malloc(), but I definitely > refuse to use free() in a critical industrial control system :-) :-). > > At least in industrial control systems the main reason for avoiding > malloc is the dynamic memory pool fragmentation over decades of > operation. > > Such systems are designed to work 10 (contractual requirement) to 50 > years continuously without reboots. In many practical system, the > next available boot time for clearing fragmented memory pool, might be > possible at Feb 29th, 2016, when some big mechanical updates are done > at the plant. There have recently been adverts for people to supply and maintain PDP-11 systems for nuclear power plants. Until *2050*! Who'd-a-thought PDP11s would still be a valid career option for youngsters. > At least that was the situation, when dedicated high reliability (and > expensive) was used. > > Unfortunately these days, quite often some unreliable COTS hardware is > used, forcing to use double or triple redundant systems. > > With a redundant system, rebooting a node is not a big difference, so > memory leaking applications or memory pool fragmentation applications > can be used. > > A redundant system makes it possible to hide some long time design > bugs, which in the long run is a serious situation. > >> >>> More subtly, interpreted = slow. To thoroughly confuse them, >>> I point them to HP's Dynamo experience where an >>> emulated processor running C outperforms the same >>> non-emulated processor running optimised C (because >>> the emulation enables the system to optimise the >>> code that is actually executed, rather than the >>> code that the compiler is forced to conservatively >>> guess will be executed. >> >> Yup. Or, "hand optimized" is better than the compiler's >> optimizer. Or, vice versa. Too much folklore and not >> enough hard/empirical data! Yet, people rely on these >> assumptions to make significant design decisions... :< > > While in the 1970's it was relatively easy to write an assembler > program based on original specifications, trying to hand code some > tested/working FORTRAN programs, I usually failed (speed/size). > > With current processors, the compilers will make a much better job. > However in some rare cases, it is important to be able to tell what > exact code (such as machine instruction) should be generated. Only for well-specified languages, which specifically excludes C/C++ and derivatives. One Big Hint to the scarcely concealed complexity is the number of command line options for the compiler and linker. Scary. Another Big Hint is that C/C++ has only just decided that a memory model is necessary - because synchronisation is specifically defined to be outside the definition of the language (i.e. library specific), so the libraries have to rely on the specific compiler/linker implementation. Oh, maybe I should note that I don't care if the program executes much faster if it doesn't give the correct answer because the compiler/linker options were inappropriate.
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 16:41 -0700 |
| Message-ID | <kt1lqt$ric$1@speranza.aioe.org> |
| In reply to | #12772 |
Hi Tom, >>> E.g., rather than replace existing/damaged land lines, providers >>> would like to provide residences with "immobile cellular stations" >>> that give them access to the wireless network at their "fixed" >>> home-line. >> >> Being downgraded from some ISDN 2B+D service to some packet switching >> system is definitely a loss. >> >> At least in Europe, service providers put 4 cellular phone links into >> a single 64 kbit/s B channel. >> >> Going from circuit switching to packet switching saves a lot for the >> service provider, when no capacity is needed, when the customer is >> "silent". > > That's true, but missing the point. POTS lines have > availability guarantees backed by *statutes*. Cellular > systems don't. Exactly. So, when a provider says, "Hey, rather than fix all these downed lines (because we didn't think ahead to bury the utilities below grade), we'll give each affected homeowner a little box that they can plug in (and pay for its power!) that gives them the same old RJ11 outlets into which they can plug their phones to connect to the PSTN" there is a fair bit of deception going on. Sure, this can save a boatload of money/labor costs. But, it also means those "land lines" are now no longer land lines and don't have to follow the same *rules* as real land lines! >>>> The "correct reason" for avoiding malloc and >>>> recursion is to enable the possibility of >>>> correctness proofs. But you know that. >> >> <clip> >> >>> The malloc argument I think is just a failure of folks to think >>> about how memory is consumed in their application and, how the heap >>> is administered/implemented in their runtime. E.g., I can often >>> guarantee that malloc handles requests in *constant* time. So, >>> why *not* use it? > > That guarantee does, of course, depend on the > specific implementation of malloc. *And* the nature of the application! That's the whole point: if you understand the implementation and your memory usage patterns, you can use these mechanisms with a much greater level of confidence. > Some mallocs > have suboptimum behaviour, particularly when they can't > locate a suitable free block. I recently crafted a "parameterized" dynamic memory manager. (trying not to use the name "malloc" since malloc has hysterical significance and connotations). E.g., you a heap (arena) that you want to operate on, the size of the request, the criteria that the allocator should use to select the appropriate fragment from the free list, what it should *do* with that fragment after it has selected it (i.e., return it en toto or cut it to fit the request... and, *where* to cut it: save the head or save the tail!), and, how any "leftover" is reintroduced to the free list. [A similar set of arguments apply to "free"] So, by careful choice of parameters, I can dice a heap into a bunch of fixed size "buffers" (aka "memory pool"/partition) and then have the allocator subsequently pick among those buffers to suit my future requests. Or, issue one set of requests/releases to the head of the arena and another set to the *tail* so the requests never interfere with each other (effectively creating two heaps that share the space of one: so, if one is underused, the other can "use more") It was tedious to code and test (since it is chock full of invariants to ensure memory is used correctly at runtime) but *seems* to have been a worthwhile exercise. At the very least, it has let me easily explore the efficiencies of different implementation options in a real runtime! >> I have absolutely nothing against using malloc(), but I definitely >> refuse to use free() in a critical industrial control system :-) :-). If you know how memory is being used, this doesn't have to be a problem. I've designed many applications that aren't intended to be reset. I've never heard of one crashing because of a heap problem. >> At least in industrial control systems the main reason for avoiding >> malloc is the dynamic memory pool fragmentation over decades of >> operation. >> >> Such systems are designed to work 10 (contractual requirement) to 50 >> years continuously without reboots. In many practical system, the >> next available boot time for clearing fragmented memory pool, might be >> possible at Feb 29th, 2016, when some big mechanical updates are done >> at the plant. > > There have recently been adverts for people to supply > and maintain PDP-11 systems for nuclear power plants. > Until *2050*! See my comment, elsewhere, re: 6502's. At least the 11 was a respectable machine! :-/ >> While in the 1970's it was relatively easy to write an assembler >> program based on original specifications, trying to hand code some >> tested/working FORTRAN programs, I usually failed (speed/size). >> >> With current processors, the compilers will make a much better job. >> However in some rare cases, it is important to be able to tell what >> exact code (such as machine instruction) should be generated. > > Only for well-specified languages, which specifically > excludes C/C++ and derivatives. One Big Hint to the > scarcely concealed complexity is the number of command > line options for the compiler and linker. Scary. > Another Big Hint is that C/C++ has only just decided > that a memory model is necessary - because synchronisation > is specifically defined to be outside the definition > of the language (i.e. library specific), so the libraries > have to rely on the specific compiler/linker implementation. I find NOT having access to the carry to be a huge impediment in squeezing the last few percent out of many algorithms. But, I work hard NOT resorting to dropping into ASM *just* to write a tiny fragment that *can* exploit the carry. OTOH, if I have written a portion of some subsystem (e.g., scheduler/dispatcher) in ASM, I take full advantage of that opportunity! :> > Oh, maybe I should note that I don't care if the > program executes much faster if it doesn't give > the correct answer because the compiler/linker > options were inappropriate. Exactly. Compiler/linker switches should just affect size of executable (in time and space). "Whaddya mean 0xFF is now '255.' and not the '-1' that I had intended?" How much of the vagary in these language specs is a consequence of politics? How much a consequence of accommodating variations in hardware (recall, one's compliment and sign/magnitude machines were in use when C had its origins...) Kinda unfair to judge based on what has become the norm (in hardware) nowadays. --don
[toc] | [prev] | [next] | [standalone]
| From | Don Y <this@isnotme.com> |
|---|---|
| Date | 2013-07-27 16:49 -0700 |
| Message-ID | <kt1map$svn$1@speranza.aioe.org> |
| In reply to | #12782 |
On 7/27/2013 4:41 PM, Don Y wrote:
>> That's true, but missing the point. POTS lines have
>> availability guarantees backed by *statutes*. Cellular
>> systems don't.
>
> Exactly. So, when a provider says, "Hey, rather than fix all
> these downed lines (because we didn't think ahead to bury the
> utilities below grade), we'll give each affected homeowner a
> little box that they can plug in (and pay for its power!)
> that gives them the same old RJ11 outlets into which they can
> plug their phones to connect to the PSTN" there is a fair bit
> of deception going on.
>
> Sure, this can save a boatload of money/labor costs. But, it
> also means those "land lines" are now no longer land lines
> and don't have to follow the same *rules* as real land lines!
From:
<http://newyork.cbslocal.com/2013/07/09/verizon-using-fire-island-to-test-getting-rid-of-landline-phones/>
If New York and New Jersey refuse to give permanent permission
for the switch from landline to wireless phone service, Verizon
could be forced to rebuild the phone network on Fire Island and
in Mantoloking. Unlike cable and wireless companies, landline
phone companies have regulatory obligations in most states to
supply lines at a reasonable cost to anyone who wants one. They
also need federal approval to end service.
Note that this conveniently fails to mention the QoS issues! :>
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-07-28 08:39 +0300 |
| Message-ID | <fda9v8pt7c782rse5mcrce4eef6u461tkc@4ax.com> |
| In reply to | #12772 |
On Sat, 27 Jul 2013 22:42:11 +0100, Tom Gardner <spamjunk@blueyonder.co.uk> wrote: >On 27/07/13 20:53, upsidedown@downunder.com wrote: >> Such systems are designed to work 10 (contractual requirement) to 50 >> years continuously without reboots. In many practical system, the >> next available boot time for clearing fragmented memory pool, might be >> possible at Feb 29th, 2016, when some big mechanical updates are done >> at the plant. > >There have recently been adverts for people to supply >and maintain PDP-11 systems for nuclear power plants. >Until *2050*! > >Who'd-a-thought PDP11s would still be a valid career >option for youngsters. I very much doubt that youngsters would be interested. My guess that the youngest would be born in 1980 and done some assembler work (on any platform) in the late 1990's, so they would be 70 years old in 2050. Trying to extend the NPP lifetime to 60-70 years require practically a rolling update of everything (except for the pressure vessel) during that period, typically a mid-life update. NPP control systems are typically updated after 20-30 years, except for instance Fukushima, where the control room looked so 1960/70´s:-). >> While in the 1970's it was relatively easy to write an assembler >> program based on original specifications, trying to hand code some >> tested/working FORTRAN programs, I usually failed (speed/size). >> >> With current processors, the compilers will make a much better job. >> However in some rare cases, it is important to be able to tell what >> exact code (such as machine instruction) should be generated. >Oh, maybe I should note that I don't care if the >program executes much faster if it doesn't give >the correct answer because the compiler/linker >options were inappropriate. I was not referring to speed, but rather features needed to write an operating system for a strange processor. If the processor has a lot of kernel mode only instructions, say for setting up memory mapping or cache control registers, how are you going to control it with some high level language ? Things are easy with clean orthogonal architectures with all hardware registers memory mapped, like the PDP-11, in which everything can be controlled with assignment statements. Still even PDP-11 had special instructions like Move from/to previous I/D space.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-27 23:11 -0700 |
| Message-ID | <7xli4rqkn8.fsf@ruckus.brouhaha.com> |
| In reply to | #12787 |
upsidedown@downunder.com writes: >>There have recently been adverts for people to supply and maintain >>PDP-11 systems for nuclear power plants. Until *2050*! >>Who'd-a-thought PDP11s would still be a valid career >>option for youngsters. > I very much doubt that youngsters would be interested. ... > Things are easy with clean orthogonal architectures with all hardware > registers memory mapped, like the PDP-11, The PDP-11 isn't especially hard to learn or program, so I think the issue of maintaining old ones has more to do with keeping the hardware alive, finding replacement parts, etc. Think of weird Unibus peripherals etc. And of course using anything but original parts would require a messy certification process for the replacements.
[toc] | [prev] | [next] | [standalone]
| From | Roberto Waltman <usenet@rwaltman.com> |
|---|---|
| Date | 2013-07-31 16:15 -0400 |
| Message-ID | <npriv894rnicr23tfokllj4r1obf8dv28u@4ax.com> |
| In reply to | #12788 |
Paul Rubin wrote: >The PDP-11 isn't especially hard to learn or program, so I think the >issue of maintaining old ones has more to do with keeping the hardware >alive, finding replacement parts, etc. And for SW maintenance, knowing how to conjure the pixies of QIOs, ASTs, and SYSGEN... -- Roberto Waltman [ Please reply to the group, return address is invalid ]
[toc] | [prev] | [next] | [standalone]
| From | upsidedown@downunder.com |
|---|---|
| Date | 2013-08-01 00:13 +0300 |
| Message-ID | <69viv8lv0p25n374q0d567qda3260pl1gv@4ax.com> |
| In reply to | #12885 |
On Wed, 31 Jul 2013 16:15:48 -0400, Roberto Waltman <usenet@rwaltman.com> wrote: >Paul Rubin wrote: >>The PDP-11 isn't especially hard to learn or program, so I think the >>issue of maintaining old ones has more to do with keeping the hardware >>alive, finding replacement parts, etc. > >And for SW maintenance, knowing how to conjure the pixies of QIOs, >ASTs, and SYSGEN... ASTs (Asynchronous System Trap) are essentially Windows callbacks. Most interesting QIO parameters are available in Windows callback parameters. SYSGEN was essential for PDP-11 system building, on VAX/VMS the question was really can you do some essential performance improvement by doing some kernel mode tweaking, on Windows NT 3.x VM tweaking was quite hard.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-27 15:16 -0700 |
| Message-ID | <7x8v0rk5so.fsf@ruckus.brouhaha.com> |
| In reply to | #12771 |
upsidedown@downunder.com writes: > Such systems are designed to work 10 (contractual requirement) to 50 > years continuously without reboots.... That sounds pretty outlandish. I'd like to know what kind of hardware that is. > Unfortunately these days, quite often some unreliable COTS hardware is > used, forcing to use double or triple redundant systems. I've never heard of a serious high-reliability system (COTS or otherwise) that doesn't use redundancy. Joe Armstrong (Erlang inventor) likes to say that a non-redundant system can't be called reliable, since the power cord is a single point of failure.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 23:05 +0100 |
| Message-ID | <avXIt.22876$FS6.20500@fx10.am4> |
| In reply to | #12774 |
On 27/07/13 23:16, Paul Rubin wrote: > upsidedown@downunder.com writes: >> Such systems are designed to work 10 (contractual requirement) to 50 >> years continuously without reboots.... UK POTS telephone exchanges had a requirement for a specified number of minutes downtime in its 40 year lifetime. Not quite the same thing, but close. > That sounds pretty outlandish. I'd like to know what kind of hardware > that is. > >> Unfortunately these days, quite often some unreliable COTS hardware is >> used, forcing to use double or triple redundant systems. > > I've never heard of a serious high-reliability system (COTS or > otherwise) that doesn't use redundancy. Joe Armstrong (Erlang inventor) > likes to say that a non-redundant system can't be called reliable, since > the power cord is a single point of failure. One should always distinguish "high availability" from "high reliability". Telco systems are typically HA without necessarily being HR.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-27 15:37 -0700 |
| Message-ID | <7xd2q3eij2.fsf@ruckus.brouhaha.com> |
| In reply to | #12776 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> 50 years continuously without reboots.... > UK POTS telephone exchanges had a requirement for a specified number > of minutes downtime in its 40 year lifetime. Not quite the same thing, > but close. Not remotely the same as keeping the same piece of hardware running for that long. Phone switches have methods of dealing with failing hardware, and of upgrading the software while the switch is running. Erlang has hot-upgrade features built into the language runtime. In other systems, you load and boot new code on the backup processor, then shut off hte main processor, causing a graceful failover. That's a slow moving reboot and in principle you could handle something like memory fragmentation that way if you noticed a degradation (of course you'd fix the problem causing the fragmentation, you wouldn't just keep rebooting). FWIW, I worked on one of those systems some years back, and the code and coding processes were basically crap. They kept the product reliable by 1) very thorough testing, and 2) relying (I think without realizing it) on the fact that in a program of that sort, most of the code paths are never exercised, so there were probably 1000's of bugs in the system that nobody ever happened to trigger.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-27 23:38 +0100 |
| Message-ID | <wZXIt.17660$GQ5.1861@fx22.am4> |
| In reply to | #12778 |
On 27/07/13 23:37, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>>> 50 years continuously without reboots.... >> UK POTS telephone exchanges had a requirement for a specified number >> of minutes downtime in its 40 year lifetime. Not quite the same thing, >> but close. > > Not remotely the same as keeping the same piece of hardware running for > that long. Phone switches have methods of dealing with failing > hardware, and of upgrading the software while the switch is running. What software is that? The systems I was referring to were pre-computer Strowager exchanges based largely on PO type 3000 relays :) Made for a bloody noisy environment during busy hour! > Erlang has hot-upgrade features built into the language runtime. In > other systems, you load and boot new code on the backup processor, then > shut off hte main processor, causing a graceful failover. That's a slow > moving reboot and in principle you could handle something like memory > fragmentation that way if you noticed a degradation (of course you'd fix > the problem causing the fragmentation, you wouldn't just keep > rebooting). I'd have liked to use Erlang, but could never justify it. > FWIW, I worked on one of those systems some years back, and the code and > coding processes were basically crap. They kept the product reliable by > 1) very thorough testing, I doubt it. You can't test quality into a product. I expect there was a solid architecture, specification and design, and they tested that the implementation conformed to those.
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-27 16:08 -0700 |
| Message-ID | <7xa9l7txcd.fsf@ruckus.brouhaha.com> |
| In reply to | #12779 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: >> They kept the product reliable by 1) very thorough testing, > I doubt it. You can't test quality into a product. I don't know if I'd use the term "quality" to describe the code what came out the other end, but it did work pretty solidly once delivered to customers. I used to wonder why it didn't collapse. I think the main thing protecting it was that it didn't have to deal with unrestricted user input like a desktop application, or do much complex processing like a compiler does. Each unit was configured and tested before delivery and I guess not reconfigured once in the field. So it was in some ways like an appliance: just a few combinations of input were possible once it was in the customer's hands. > I expect there was a solid architecture, specification and design, > and they tested that the implementation conformed to those. Wishful thinking. It was designed by electrical engineers who were smarter than hell but didn't know anything about software. So they were able to write crazy and intricate code and actually get it to work, but it was near-unmaintainable (premature optimization was a recurring theme). It had tons of written specs per ISO 9002 but the specs didn't have much to do with the internals of the code. Meanwhile I hear that SpaceX is using C++ to program what will eventually be manned spacecraft. Shudder.
[toc] | [prev] | [next] | [standalone]
| From | Tom Gardner <spamjunk@blueyonder.co.uk> |
|---|---|
| Date | 2013-07-28 01:16 +0100 |
| Message-ID | <EpZIt.5612$Sr7.5577@fx08.am4> |
| In reply to | #12780 |
On 28/07/13 00:08, Paul Rubin wrote: > Tom Gardner <spamjunk@blueyonder.co.uk> writes: >>> They kept the product reliable by 1) very thorough testing, >> I doubt it. You can't test quality into a product. > > I don't know if I'd use the term "quality" to describe the code what > came out the other end, but it did work pretty solidly once delivered to > customers. I used to wonder why it didn't collapse. I think the main > thing protecting it was that it didn't have to deal with unrestricted > user input like a desktop application, or do much complex processing > like a compiler does. Each unit was configured and tested before > delivery and I guess not reconfigured once in the field. So it was in > some ways like an appliance: just a few combinations of input were > possible once it was in the customer's hands. > >> I expect there was a solid architecture, specification and design, >> and they tested that the implementation conformed to those. > > Wishful thinking. It was designed by electrical engineers who were > smarter than hell but didn't know anything about software. In which case I expect that the system architecture and specification would be good, since h/w engineers automatically avoid many traps[*] that softies seem to actively throw themselves into. The implementation of the specification in s/w might well be a different kettle of (smelly) fish! Or ugly C code might have been auto-generated from a clean higher level specification (e.g. an FSM) that is very similar to the way the system is specified. That technique is common in the telco and network world. [*] especially those related to distributed interacting systems with long lifetimes > So they were > able to write crazy and intricate code and actually get it to work, but > it was near-unmaintainable (premature optimization was a recurring > theme). It had tons of written specs per ISO 9002 but the specs didn't > have much to do with the internals of the code. ISO9000 is all to do with process, not quality. > Meanwhile I hear that SpaceX is using C++ to program what will > eventually be manned spacecraft. Shudder. Don't uy any property downrange of the launch site :)
[toc] | [prev] | [next] | [standalone]
| From | Paul Rubin <no.email@nospam.invalid> |
|---|---|
| Date | 2013-07-27 18:43 -0700 |
| Message-ID | <7xhaffxxv5.fsf@ruckus.brouhaha.com> |
| In reply to | #12784 |
Tom Gardner <spamjunk@blueyonder.co.uk> writes: > In which case I expect that the system architecture and > specification would be good, since h/w engineers automatically > avoid many traps[*] that softies seem to actively throw > themselves into. I don't have any reason to doubt the hardware design was good, though it's not my area and I didn't see into it very much. The initial software architecture may also have made sense at some level. After a decade or so of patches and upgrades by dozens of programmers, any clarity had long since vanished. > Or ugly C code might have been auto-generated It wasn't anything like that. It was handwritten and too clever by half. They "optimized" all over the place without profiling anything to know where the cycles were actually going. I remember one module had to check the status of a few hundred channels in some sorted order. It had a single C function around 20 pages long, full of clever coding tricks and code duplication to avoid unnecessary work. Of course it amounted to a micro-optimized O(N**2) sorting algorithm smeared through all that code (this particular module may have actually been chewing cycles, but most weren't). Replacing it with a reasonable algorithm made the code 1/4 of the size and orders of magnitude faster, optimizations not needed. Ericsson's codebase was apparently in sort of similar condition when they switched from C to Erlang in the 1980's(?), so I guess this is a familiar story. > [*] especially those related to distributed interacting > systems with long lifetimes This wasn't really a distributed system. It had two CPU's (primary and failover) with a communication channel and some shared peripherals. That aspect of the architecture wasn't too bad, but the upgrade/failover code was somewhat horrendous since the stuff that had to be communicated between the CPU's wasn't really localized in the codebase. You had to just hope that if you missed anything, it would show up in QA instead of causing some subtle failure in the field.
[toc] | [prev] | [next] | [standalone]
Page 3 of 6 — ← Prev page 1 2 [3] 4 5 6 Next page →
Back to top | Article view | comp.arch.embedded
csiph-web