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

Groups > comp.arch.embedded > #30292

Re: RPC/RMI in heterogeneous environments

Show all headers | View raw

On Sun, 31 Jan 2021 12:37:27 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 1/29/2021 11:33 AM, upsidedown@downunder.com wrote:
>> On Thu, 21 Jan 2021 18:38:27 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>> 
>>> I postpone automatic type conversion to the *servant*, rather
>>> than embedding it in the client-side stub.  My reasoning is
>>> that this allows a wider window for the targeted node to change
>>> *after* the RPC/RMI invocation and before it's actual servicing.
>> 
>> You must be quite desperate (extreme data rate, flea power client,
>> very small memory client)  for even considering functionality that
>> naturally belongs to the client.
>
>It's "power" (resource) related only in that time = 1/"power"

Computing power (and hence power consumption) is often exchangeable
with time. Thus the _energy_ consumption of a complex operation can be
nearly constant. This can be an issue in truly flee power systems, in
which you may have to find algorithms with less complexity to reduce
total energy consumption,

>
>> Any healthy clients can handle byte order, time zones, character sets
>> and languages.
>
>Convert Q10.6 to double

Q10.6 is already in binary representation fitting into a 16 bit word
or two bytes.  Just some shifting to do the hidden bit normalization
and some exponent adjustment and you are done. Should be easy with
even any 8 bit processor. Doing it with some primitive 4 bitters (e.g.
(4004/4040) would require more swapping between internal registers.

Of course a decimal number with 10 integer digits and 6 fractional
digits (either in BCD/ASCII/EBCDIC) requires much more work and
scratchpad areas.

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

Thread

RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-21 18:38 -0700
  Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-25 01:58 -0500
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 00:06 -0700
      Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-26 13:23 -0500
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-26 13:39 -0700
          Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-01-28 21:08 -0500
            Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 11:44 -0700
              Re: RPC/RMI in heterogeneous environments George Neuner <gneuner2@comcast.net> - 2021-02-01 15:50 -0500
                Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 21:19 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-29 20:33 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 12:37 -0700
      Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-02-01 08:50 +0200
        Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-02-03 20:53 -0700
  Re: RPC/RMI in heterogeneous environments upsidedown@downunder.com - 2021-01-31 21:39 +0200
    Re: RPC/RMI in heterogeneous environments Don Y <blockedofcourse@foo.invalid> - 2021-01-31 15:21 -0700

csiph-web