Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26382

Re: exposing resource usage

Show all headers | View raw

On 4/17/2017 10:24 AM, upsidedown@downunder.com wrote:
> On Fri, 14 Apr 2017 10:22:28 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 4/14/2017 5:33 AM, upsidedown@downunder.com wrote:
>>> On Fri, 14 Apr 2017 12:53:54 +0300, upsidedown@downunder.com wrote:
>>>
>>>
>>>> These days the hardware is so cheap that for a RT / high reliability
>>>> system, I recommend 40-60 % usage of CPU channels and communications
>>>> links. Going much higher than that, is going to cause problems sooner
>>>> or later.
>>>
>>> I just realized how old I am (still one of the youngest in CAE and
>>> especially SED newsgroups). During my career in various forms of
>>> computing, the prace/performance  has been improved by a ratio one to
>>> a million, depending on how you interpret the Moore's law (is the
>>> price/performance ratio doubling every 18 or 24 months). With such
>>> huge rations, it is cost effective to do things in one way and other
>>> 2-4 years in a completely different way.
>>
>> I started work on "embedded" products with the i4004 -- with clock
>> rates in the hundreds of kilohertz and instruction execution times
>> measured in tens of microseconds -- for *4* bit quantities!  *Simple*
>> operations (e.g., ADD) on "long ints" were on the order of a MILLIsecond.
>> Memory was measured in kiloBITS, etc.
>
> You need to consider the inpput/output speeds. Essentially the 4004
> was a calculator chip with steroids. The input speed for a manual
> calculator is about 100 ms/decimal digit and one expects that the
> result is displayed in a second, so you could do quite complicated
> computations even with a 1 ms (long) decimal add time.

We used it to plot current position based on real-time receipt of
LORAN-C coordinates:
    <https://en.wikipedia.org/wiki/Loran-C>

Each "coordinate axis" (i.e., X & Y, latitude & longitude, etc.)
in LORAN consists of a family of hyperbolic "lines of constant
time difference":
   <https://en.wikipedia.org/wiki/File:Crude_LORAN_diagram.svg>
between a master transmitter and one of its slaves (A&B in the
diagram).  With families from *two* such slaves INTERSECTING,
you can "uniquely" [1] determine your location on the globe
(knowing the latitude and longitude of the master and associated
slaves, the shape of the earth, propagation time of radio waves
and "conic sections").

[1] This is a lie as a single hyperbolic curve from one family
(time-difference coordinate #1) can intersect another hyperbolic
curve from another family (TD coordinate #2) at *two* points,
unlike a (latitude,longitude) tuple that is unique.  To confirm
this, print two copies of the above sample and skew them so
AB is not parallel to AC (assume C is the renamed B on the second
instance)

Coordinates are processed at a rate of 10GRI (10 sets of
transmissions -- GRI is the time between transmissions from the master;
    <https://en.wikipedia.org/wiki/Loran-C#LORAN_chains_.28GRIs.29>).
Each is typically about 50-100ms so 10GRI being 500-1000ms.

It's a fair bit of work to resolve two hyperbolae on an oblate
sphere mapped to a scaled Mercator projection and drive two
stepper motors to the corresponding point before the next
"fix" arrives.

This is the second generation (8085-based) version (bottom, center):
 
<http://www.marineelectronicsjournal.com/Assets/lew%20and%20jim%20best%20copy.jpg>
By then, the code space had soared to a whopping 12KB (at one time,
close to $300 of EPROM!) -- with all of 512 bytes of RAM!!

> Just calculated that the 4004 would have been sufficient to handle
> summation of data from a slow card reader (300 CPM, cards per minute)
> so with ten 8 digit decimal number on each card, you would have to
> handle 50 long decimal numbers each second. Using a medium speed (1000
> CPS characters per second) paper tape, this would be 125 long decimal
> integers/s, which would quite hard for the 4004 to handle.
>
> Simple decimal computers in the 1960's  often used a 4 bit BCD ALU and
> handled decimal digits serially.   This still required a lot of DTL or
> TTL chips and the CPU cost was still significant.

The Z80 was still a 4b ALU (multiple clocks to process 8b data)

> With the introduction of LSI chips, the cost dropped significantly in
> a few years.
>
> Any programmable calculator today will outperform any 1960's decimal
> computer by a great margin at a very small fractional cost.
>
> If things were done in one way in the past with different constraints,
> implementing it today the same way might not make sense.

Of course!  I suspect I could reproduce the software for the plotters
in a long weekend, now.  No need to write a floating point library,
multiplex PGD displays, scan keypads, drive motor coils, count
*bits* of storage, etc.  Just use <math.h> and a graphics library to
plot line segments on a display "instantaneously".  Load a set
of maps from FLASH, etc.

> The 4004 had a nice 4 KiB program space. Small applications even in
> the 1980's didn't need more and reprogramming a 4 KiB EPROM took just
> 5 minutes :-)

You were using 1702's in the mid 70's -- 2Kb (not KB!) parts.

Back to comp.arch.embedded | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 18:22 -0700
  Re: exposing resource usage Robert Wessel <robertwessel2@yahoo.com> - 2017-04-13 20:56 -0500
    Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-13 22:26 -0700
    Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 10:24 +0300
      Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 00:53 -0700
        Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 12:53 +0300
          Re: exposing resource usage upsidedown@downunder.com - 2017-04-14 15:33 +0300
            Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:22 -0700
              Re: exposing resource usage upsidedown@downunder.com - 2017-04-17 20:24 +0300
                Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-17 12:13 -0700
            Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-14 21:26 +0300
              Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 12:45 -0700
                Re: exposing resource usage Dimiter_Popoff <dp@tgi-sci.com> - 2017-04-15 00:27 +0300
                Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 20:45 -0700
          Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 10:11 -0700
  Re: exposing resource usage Tim Wescott <seemywebsite@myfooter.really> - 2017-04-14 12:54 -0500
    Re: exposing resource usage Don Y <blockedofcourse@foo.invalid> - 2017-04-14 11:44 -0700

csiph-web