Path: ...!weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Tim Rentsch <tr.17687@z991.linuxsc.com>
Newsgroups: comp.lang.c
Subject: Re: Top 10 most common hard skills listed on resumes...
Date: Mon, 09 Sep 2024 12:08:09 -0700
Organization: A noiseless patient Spider
Lines: 94
Message-ID: <861q1sk5ly.fsf@linuxsc.com>
References: <vab101$3er$1@reader1.panix.com> <valrj7$367a8$2@dont-email.me> <87mskwy9t1.fsf@bsb.me.uk> <vanq4h$3iieb$1@dont-email.me> <875xrkxlgo.fsf@bsb.me.uk> <vapitn$3u1ub$1@dont-email.me> <87o75bwlp8.fsf@bsb.me.uk> <vaps06$3vg8l$1@dont-email.me> <871q27weeh.fsf@bsb.me.uk> <20240829083200.195@kylheku.com> <87v7zjuyd8.fsf@bsb.me.uk> <20240829084851.962@kylheku.com> <87mskvuxe9.fsf@bsb.me.uk> <vaq9tu$1te8$1@dont-email.me> <vbci8r$1c9e8$1@paganini.bofh.team> <20240905094916.287@kylheku.com> <vbd8b8$g8iv$1@dont-email.me> <vbeick$p6kd$1@dont-email.me> <20240906140541.00004c8f@yahoo.com> <864j6somo7.fsf@linuxsc.com> <20240908115334.00006322@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Date: Mon, 09 Sep 2024 21:08:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="2550a8cb929efdfde26bde1f2c6c70c6";
	logging-data="2650530"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/bykUCObUdwO69RbN1DGiHFisEvPwxS/c="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:Y7PbaaxeLQJW2izwj3XzD649INs=
	sha1:y4CA1IVsyF8LIGNXCG9NEUQeL5w=
Bytes: 5134

Michael S <already5chosen@yahoo.com> writes:

> On Fri, 06 Sep 2024 07:56:56 -0700
> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>
>> Michael S <already5chosen@yahoo.com> writes:
>>
>>> On Fri, 6 Sep 2024 10:35:16 +0100
>>> Bart <bc@freeuk.com> wrote:
>>>
>>>> On 05/09/2024 22:37, James Kuyper wrote:
>>>>
>>>>> On 9/5/24 12:54, Kaz Kylheku wrote:
>>>>>
>>>>>> On 2024-09-05, Waldek Hebisch <antispam@fricas.org> wrote:
>>>>>
>>>>> ...
>>>>>
>>>>>>> You seem to miss the point that assigment operator is
>>>>>>> fundamentally assymetic.
>>>>>>
>>>>>> Both sides of an assignment can be complex expressions that
>>>>>> designate an object (though the right side need not).
>>>>>
>>>>> So you've correctly identified the very fundamental asymmetry.
>>>>
>>>> Sure, if you want to completely disregard all the cases where the
>>>> symmetry does exist.
>>>>
>>>> That means that for you, there is no interesting difference (using
>>>> my example of assigning A to itself) in a language where you write
>>>> 'A = A', and one where you write 'A = .A'.
>>>>
>>>> (I'd be interested in how, in the latter language, you'd write the
>>>> equivalent of 'A = A = A' in C, since the middle term is both on
>>>> the left of '=', and on the right!)
>>>
>>> The point is that in BLISS everithing that is legal on the right
>>> side of asignment is also legal on the left side.
>>> I don't know if the point is generally true.  In particular, if
>>> BLISS supports floatig point, what is meaning of floating point on
>>> the left side?
>>
>> BLISS is word based and typeless.  On a PDP-10, doing a
>>
>>     .pi = 0
>>
>> where 'pi' holds a 36-bit floating-point value (and 3.14159...
>> presumably), that floating-point value would be used as an
>> address and 0 would be stored into it (assuming I remember
>> BLISS correctly).
>
> On PDP-10 reinterpreting [18 LS bits of] floating-point as address is
> natural, because addresses, integers and FP share the same register
> file.
> It seems to me that on S/360 or CDC-6K or PDP-11 or VAX it would be
> less natural.

I don't think one thing has much of anything to do with the
other.  It seems just as unlikely to use a floating-point value,
or a portion of a floating-point value, as an address on a PDP-10
as it does on any of the other systems you mentioned.

> However, natural or not, BLISS was used widely both on PDP-11 and on
> VAX, which means that it worked well enough.

BLISS is, or was, closer to the hardware than C.  Also it's
harder to scale in BLISS than in C, because BLISS is typeless.
Writing code in BLISS needs more discipline than writing in C.
(Disclaimer:  my experience writing code in BLISS is very
close to epsilon, and is very much dimmed by the long passage
of time.)


>> So probably not what one wants to do. ;)
>
> Yes, LS bits of FP as address do not sound very useful.
> On the other hand, using several MS bits of FP, although typically
> fewer than 18, as address is useful in calculations of many
> transcendental functions.

Probably not use it as an address but rather as an index.
Perhaps something like this (please forgive the bastard
mixing of BLISS and C):

    // variable d contains a 64-bit double

    needed = .(most_digits + (.d >> 52 & 0x1FFF))

to index a table 'most_digits' by the 11-bit exponent of a
"double" floating-point value.

I don't remember enough BLISS to know how to write indexing,
but this construction should accomplish that.