Rocksolid Light

Welcome to novaBBS (click a section below)

mail  files  register  newsreader  groups  login

Message-ID:  

A transistor protected by a fast-acting fuse will protect the fuse by blowing first.


devel / comp.arch / Any comments on:

SubjectAuthor
* Any comments on:MitchAlsup
+- Re: Any comments on:Ivan Godard
+- Re: Any comments on:Thomas Koenig
+* Re: Any comments on:Niklas Holsti
|+* Re: Any comments on:Tim Rentsch
||`* Re: Any comments on:Michael S
|| `- Re: Any comments on:Tim Rentsch
|`* Re: Any comments on:Michael S
| `- Re: Any comments on:Ivan Godard
+- Re: Any comments on:Tim Rentsch
`* Re: Any comments on:Marcus
 `* Re: Any comments on:BGB
  +* Re: Any comments on:MitchAlsup
  |+* Re: Any comments on:Ivan Godard
  ||`- Re: Any comments on:MitchAlsup
  |`* Re: Any comments on:BGB
  | `* Re: Any comments on:Ivan Godard
  |  `- Re: Any comments on:BGB
  +* Re: Any comments on:Stephen Fuld
  |+* Re: Any comments on:Ivan Godard
  ||+* Re: Any comments on:Stephen Fuld
  |||`- Re: Any comments on:Thomas Koenig
  ||`* Re: Any comments on:Thomas Koenig
  || `* Re: Any comments on:David Brown
  ||  +- Re: Any comments on:BGB
  ||  `* Re: Any comments on:Thomas Koenig
  ||   `* Re: Any comments on:David Brown
  ||    `- Re: Any comments on:BGB
  |+* Re: Any comments on:BGB
  ||`* Re: Any comments on:Stephen Fuld
  || `* Re: Any comments on:BGB
  ||  `* Re: Any comments on:Stephen Fuld
  ||   `* Re: Any comments on:BGB
  ||    `- Re: Any comments on:MitchAlsup
  |`* Re: Any comments on:Tim Rentsch
  | `* Re: Any comments on:BGB
  |  `- Re: Any comments on:Tim Rentsch
  +* Re: Any comments on:Niklas Holsti
  |`* Re: Any comments on:MitchAlsup
  | `- Re: Any comments on:Niklas Holsti
  `- Re: Any comments on:Timothy McCaffrey

Pages:12
Any comments on:

<8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23966&group=comp.arch#23966

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:4649:0:b0:47e:cf47:48af with SMTP id t70-20020a374649000000b0047ecf4748afmr2875375qka.605.1646511722742;
Sat, 05 Mar 2022 12:22:02 -0800 (PST)
X-Received: by 2002:a05:6830:1b6f:b0:5af:d2f:eed9 with SMTP id
d15-20020a0568301b6f00b005af0d2feed9mr2137385ote.331.1646511722473; Sat, 05
Mar 2022 12:22:02 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sat, 5 Mar 2022 12:22:02 -0800 (PST)
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:4d67:be1c:4133:399e;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:4d67:be1c:4133:399e
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Subject: Any comments on:
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Sat, 05 Mar 2022 20:22:02 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 2
 by: MitchAlsup - Sat, 5 Mar 2022 20:22 UTC

https://www.youtube.com/watch?v=QM1iUe6IofM

I end up agreeing with the vast majority of his points and have always programmed in the fashion he describes.

Re: Any comments on:

<t00j6t$8mp$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23969&group=comp.arch#23969

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sat, 5 Mar 2022 13:03:24 -0800
Organization: A noiseless patient Spider
Lines: 9
Message-ID: <t00j6t$8mp$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sat, 5 Mar 2022 21:03:25 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8ae78d59de3dd085cc86512a8f7a8533";
logging-data="8921"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/gt9Cx4BZcRP/ketSZyos3"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:98QR/jLWQ7cEVABsx100mAKr3To=
In-Reply-To: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Sat, 5 Mar 2022 21:03 UTC

On 3/5/2022 12:22 PM, MitchAlsup wrote:
> https://www.youtube.com/watch?v=QM1iUe6IofM
>
> I end up agreeing with the vast majority of his points and have always programmed in the fashion he describes.

Rants and polemics and diatribes, oh my!

None of the above, thank you very much. I create a task-specific
language in whatever host language is commanded, and write in that.

Re: Any comments on:

<t00m77$u9p$1@newsreader4.netcologne.de>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23970&group=comp.arch#23970

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd4-fef8-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoe...@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sat, 5 Mar 2022 21:54:47 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <t00m77$u9p$1@newsreader4.netcologne.de>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Injection-Date: Sat, 5 Mar 2022 21:54:47 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-fef8-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:fef8:0:7285:c2ff:fe6c:992d";
logging-data="31033"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Sat, 5 Mar 2022 21:54 UTC

MitchAlsup <MitchAlsup@aol.com> schrieb:
> https://www.youtube.com/watch?v=QM1iUe6IofM

It suffers from being a Youtube video instead of an article.
I could have read a blog article in five minutes, I'm not going
to listen to somebody talking in a video for 45 minutes.

Re: Any comments on:

<j8i73cFqgenU1@mid.individual.net>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23971&group=comp.arch#23971

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!news.swapon.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: niklas.h...@tidorum.invalid (Niklas Holsti)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sun, 6 Mar 2022 00:38:35 +0200
Organization: Tidorum Ltd
Lines: 27
Message-ID: <j8i73cFqgenU1@mid.individual.net>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: individual.net wDAPohIRthG2UgQ1WMzS9gEZje7ayUexT22eIG0TsusJwIJj/G
Cancel-Lock: sha1:RNsqbU7XV7QMQD2ejeUmcWi5Kxo=
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:91.0)
Gecko/20100101 Thunderbird/91.6.0
Content-Language: en-US
In-Reply-To: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
 by: Niklas Holsti - Sat, 5 Mar 2022 22:38 UTC

On 2022-03-05 22:22, MitchAlsup wrote:
> https://www.youtube.com/watch?v=QM1iUe6IofM
>
> I end up agreeing with the vast majority of his points and have
> always programmed in the fashion he describes.

He seems to be a guy who tried to follow and believe the pure
object-oriented dogma and the gurus who propound it, but then found it
not to be the (whole) truth, and lapsed from the faith. Good for him.

But, as for most arguments against fundamentalist (quasi-)religious
doctrines, his arguments against pure object-orientation are tedious and
over-elaborated. He has a shorter, later, and more concrete video
showing four examples of OO programs that he rewrites into procedural form:

https://youtu.be/IRTfhkiAqPw

I agree with many of his suggestions, but I think he undervalues the
maintainability and extensibility advantages of judicious use of
classes, inheritance, and encapsulation. Which of course means that my
programming style uses those more than he suggests.

Much of his argument is just damning the confusion of classes with
modules in languages like Java. I agree, but that has little to do with
the idea of object orientation. IMO this confusion (making classes play
the role of modules) is a misguided attempt to over-simplify a
programming language.

Re: Any comments on:

<86tucbg48b.fsf@linuxsc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23976&group=comp.arch#23976

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sat, 05 Mar 2022 19:16:36 -0800
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <86tucbg48b.fsf@linuxsc.com>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="13246d5653fd8faf4d64a45856686609";
logging-data="13240"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/nrbToo0Fky1mNSX35aedxfPFRS384QW4="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:8kDGF+vpkyfU4jXOaHb4bh+TKvg=
sha1:jteGDmU3h+jx5l5HVvNy1zQfAiA=
 by: Tim Rentsch - Sun, 6 Mar 2022 03:16 UTC

MitchAlsup <MitchAlsup@aol.com> writes:

> https://www.youtube.com/watch?v=QM1iUe6IofM
>
> I end up agreeing with the vast majority of his points and have
> always programmed in the fashion he describes.

I echo most of the comments made by Niklas Holsti. I think a
fair summary of his conclusions is object-oriented programming
done by people who don't understand it often turns out badly.

Re: Any comments on:

<86pmmzg3vx.fsf@linuxsc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23977&group=comp.arch#23977

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sat, 05 Mar 2022 19:24:02 -0800
Organization: A noiseless patient Spider
Lines: 33
Message-ID: <86pmmzg3vx.fsf@linuxsc.com>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com> <j8i73cFqgenU1@mid.individual.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="13246d5653fd8faf4d64a45856686609";
logging-data="13240"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19yiGrApJNPyBhhO/rhUUPPiRFHIhGXj8o="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:3ynU2B9c6cvHF6Aej8GXv7QZ2bs=
sha1:5qJta5pb7cyWatCHupAK5NPkIaQ=
 by: Tim Rentsch - Sun, 6 Mar 2022 03:24 UTC

Niklas Holsti <niklas.holsti@tidorum.invalid> writes:

> On 2022-03-05 22:22, MitchAlsup wrote:
>
>> https://www.youtube.com/watch?v=QM1iUe6IofM
>>
>> I end up agreeing with the vast majority of his points and have
>> always programmed in the fashion he describes.
>
> He seems to be a guy who tried to follow and believe the pure
> object-oriented dogma and the gurus who propound it, but then found
> it not to be the (whole) truth, and lapsed from the faith. Good for
> him.
>
> But, as for most arguments against fundamentalist (quasi-)religious
> doctrines, his arguments against pure object-orientation are tedious
> and over-elaborated. He has a shorter, later, and more concrete
> video showing four examples of OO programs that he rewrites into
> procedural form:
>
> https://youtu.be/IRTfhkiAqPw
>
> I agree with many of his suggestions, but I think he undervalues
> the maintainability and extensibility advantages of judicious use
> of classes, inheritance, and encapsulation. [...]

His example programs are (as he himself notes) only about 200
lines each.

Alan Kay has said: ten lines of Smalltalk is about the same as
ten lines of Pascal; but 20 pages of Smalltalk is about 50
pages of Pascal. And there is some amount of truth in that
comparison.

Re: Any comments on:

<aab3d145-449f-420b-abee-41a83f388e80n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23982&group=comp.arch#23982

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:c4b:b0:435:7a60:8f87 with SMTP id r11-20020a0562140c4b00b004357a608f87mr2014873qvj.85.1646563098779;
Sun, 06 Mar 2022 02:38:18 -0800 (PST)
X-Received: by 2002:a9d:2f2a:0:b0:5a0:bbdf:4b67 with SMTP id
h39-20020a9d2f2a000000b005a0bbdf4b67mr3312426otb.243.1646563098513; Sun, 06
Mar 2022 02:38:18 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 6 Mar 2022 02:38:18 -0800 (PST)
In-Reply-To: <j8i73cFqgenU1@mid.individual.net>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com> <j8i73cFqgenU1@mid.individual.net>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <aab3d145-449f-420b-abee-41a83f388e80n@googlegroups.com>
Subject: Re: Any comments on:
From: already5...@yahoo.com (Michael S)
Injection-Date: Sun, 06 Mar 2022 10:38:18 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 30
 by: Michael S - Sun, 6 Mar 2022 10:38 UTC

On Sunday, March 6, 2022 at 12:38:40 AM UTC+2, Niklas Holsti wrote:
> On 2022-03-05 22:22, MitchAlsup wrote:
> > https://www.youtube.com/watch?v=QM1iUe6IofM
> >
> > I end up agreeing with the vast majority of his points and have
> > always programmed in the fashion he describes.
> He seems to be a guy who tried to follow and believe the pure
> object-oriented dogma and the gurus who propound it, but then found it
> not to be the (whole) truth, and lapsed from the faith. Good for him.
>
> But, as for most arguments against fundamentalist (quasi-)religious
> doctrines, his arguments against pure object-orientation are tedious and
> over-elaborated. He has a shorter, later, and more concrete video
> showing four examples of OO programs that he rewrites into procedural form:
>
> https://youtu.be/IRTfhkiAqPw
>
> I agree with many of his suggestions, but I think he undervalues the
> maintainability and extensibility advantages of judicious use of
> classes, inheritance, and encapsulation. Which of course means that my
> programming style uses those more than he suggests.
>

In my personal practice, an absolute majority of uses of inheritance in C++ happens because I find [C++] syntax for delegation (i.e. pointers to member functions) hard to remember.
I'd think that if my main application development language had more "natural" syntax for delegation then I'd use inheritance much less frequently than today (which is already quite rare). May be, few times per decade.

> Much of his argument is just damning the confusion of classes with
> modules in languages like Java. I agree, but that has little to do with
> the idea of object orientation. IMO this confusion (making classes play
> the role of modules) is a misguided attempt to over-simplify a
> programming language.

Re: Any comments on:

<0f95cf77-1c0a-4d71-bce7-4873b85b758cn@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23983&group=comp.arch#23983

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:2981:b0:67b:98:179e with SMTP id r1-20020a05620a298100b0067b0098179emr2745141qkp.561.1646564123648;
Sun, 06 Mar 2022 02:55:23 -0800 (PST)
X-Received: by 2002:a9d:72c6:0:b0:5af:42ef:bb7c with SMTP id
d6-20020a9d72c6000000b005af42efbb7cmr3259728otk.96.1646564123412; Sun, 06 Mar
2022 02:55:23 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Sun, 6 Mar 2022 02:55:23 -0800 (PST)
In-Reply-To: <86pmmzg3vx.fsf@linuxsc.com>
Injection-Info: google-groups.googlegroups.com; posting-host=199.203.251.52; posting-account=ow8VOgoAAAAfiGNvoH__Y4ADRwQF1hZW
NNTP-Posting-Host: 199.203.251.52
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<j8i73cFqgenU1@mid.individual.net> <86pmmzg3vx.fsf@linuxsc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0f95cf77-1c0a-4d71-bce7-4873b85b758cn@googlegroups.com>
Subject: Re: Any comments on:
From: already5...@yahoo.com (Michael S)
Injection-Date: Sun, 06 Mar 2022 10:55:23 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Lines: 55
 by: Michael S - Sun, 6 Mar 2022 10:55 UTC

On Sunday, March 6, 2022 at 5:24:05 AM UTC+2, Tim Rentsch wrote:
> Niklas Holsti <niklas...@tidorum.invalid> writes:
>
> > On 2022-03-05 22:22, MitchAlsup wrote:
> >
> >> https://www.youtube.com/watch?v=QM1iUe6IofM
> >>
> >> I end up agreeing with the vast majority of his points and have
> >> always programmed in the fashion he describes.
> >
> > He seems to be a guy who tried to follow and believe the pure
> > object-oriented dogma and the gurus who propound it, but then found
> > it not to be the (whole) truth, and lapsed from the faith. Good for
> > him.
> >
> > But, as for most arguments against fundamentalist (quasi-)religious
> > doctrines, his arguments against pure object-orientation are tedious
> > and over-elaborated. He has a shorter, later, and more concrete
> > video showing four examples of OO programs that he rewrites into
> > procedural form:
> >
> > https://youtu.be/IRTfhkiAqPw
> >
> > I agree with many of his suggestions, but I think he undervalues
> > the maintainability and extensibility advantages of judicious use
> > of classes, inheritance, and encapsulation. [...]
>
> His example programs are (as he himself notes) only about 200
> lines each.
>
> Alan Kay has said: ten lines of Smalltalk is about the same as
> ten lines of Pascal; but 20 pages of Smalltalk is about 50
> pages of Pascal. And there is some amount of truth in that
> comparison.

First, if he said that it does not mean that he necessarily measured that.

Second, Standard Pascal is not your average procedural language. It has an unique property of being especially bad for anything above toy scale. That's why there are so many incompatible "Extended Pascal" dialects that people use in real world. So, comparison with Pascal looks to me like a strawman..

Third, continuing the 2nd point, how do you expect 20 pages of [OOP] Java to compare against [non-OOP] Golang?
Or against [non-OOP-subset-of] Python?
My guess is that result would be quite different from Smalltalk vs Pascal and likely embarrassing for OOP proponents.

But, then again, I heard that Alan Kay himself is a harsh critic of a version of OOP that started to develop around 1985 and became a dogma during nineties. Quite likely, more harsh than myself.

Re: Any comments on:

<t02gd6$ahn$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23988&group=comp.arch#23988

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sun, 6 Mar 2022 06:27:49 -0800
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <t02gd6$ahn$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<j8i73cFqgenU1@mid.individual.net>
<aab3d145-449f-420b-abee-41a83f388e80n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 6 Mar 2022 14:27:50 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="4fd8cca3949469c3663f782922c4c99e";
logging-data="10807"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+jvudPRbiMVs+++erdPpMM"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:l+XPrRfLYN8Dv6xjrd2lHkpoKQk=
In-Reply-To: <aab3d145-449f-420b-abee-41a83f388e80n@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Sun, 6 Mar 2022 14:27 UTC

On 3/6/2022 2:38 AM, Michael S wrote:
> On Sunday, March 6, 2022 at 12:38:40 AM UTC+2, Niklas Holsti wrote:
>> On 2022-03-05 22:22, MitchAlsup wrote:
>>> https://www.youtube.com/watch?v=QM1iUe6IofM
>>>
>>> I end up agreeing with the vast majority of his points and have
>>> always programmed in the fashion he describes.
>> He seems to be a guy who tried to follow and believe the pure
>> object-oriented dogma and the gurus who propound it, but then found it
>> not to be the (whole) truth, and lapsed from the faith. Good for him.
>>
>> But, as for most arguments against fundamentalist (quasi-)religious
>> doctrines, his arguments against pure object-orientation are tedious and
>> over-elaborated. He has a shorter, later, and more concrete video
>> showing four examples of OO programs that he rewrites into procedural form:
>>
>> https://youtu.be/IRTfhkiAqPw
>>
>> I agree with many of his suggestions, but I think he undervalues the
>> maintainability and extensibility advantages of judicious use of
>> classes, inheritance, and encapsulation. Which of course means that my
>> programming style uses those more than he suggests.
>>
>
> In my personal practice, an absolute majority of uses of inheritance in C++ happens because I find [C++] syntax for delegation (i.e. pointers to member functions) hard to remember.
> I'd think that if my main application development language had more "natural" syntax for delegation then I'd use inheritance much less frequently than today (which is already quite rare). May be, few times per decade.
>
>> Much of his argument is just damning the confusion of classes with
>> modules in languages like Java. I agree, but that has little to do with
>> the idea of object orientation. IMO this confusion (making classes play
>> the role of modules) is a misguided attempt to over-simplify a
>> programming language.

I write a lot of c++, and find that there are two kinds, or perhaps two
uses, of inheritance: to augment and special-case a data structure
(circle is an instance of shape), and to mix in common behaviors
(distances support ordered pairs with includes relations). Data is
rarely inherited in my code and almost always with mono-inheritance.
Behavior inheritance is common and frequently multiple.

Often the inherited class will be a template invocation, but the two
kinds differ in how the template is used. In ehavior mixin inheritance
(one of) the template arguments is the base class itself, an instance if
the "curiously recursive" structure, while this doesn't seem used in
data inheritance.

Much of the pro/con-inheritance arguments seems to arise when a
proponent of one of these kinds of inheritance encounters a proponent of
the other kind.

Re: Any comments on:

<86zgm3dnv1.fsf@linuxsc.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=23991&group=comp.arch#23991

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: tr.17...@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Sun, 06 Mar 2022 08:53:06 -0800
Organization: A noiseless patient Spider
Lines: 97
Message-ID: <86zgm3dnv1.fsf@linuxsc.com>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com> <j8i73cFqgenU1@mid.individual.net> <86pmmzg3vx.fsf@linuxsc.com> <0f95cf77-1c0a-4d71-bce7-4873b85b758cn@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="13246d5653fd8faf4d64a45856686609";
logging-data="17804"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196xltLtRuvvTSAIFOL18NqOqFJJGNa2q0="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:ZuhYC2O5VUYvFq6m9lXx517k5oM=
sha1:t6HC3QVhEAO9OHx4MGjy+HKvA0Q=
 by: Tim Rentsch - Sun, 6 Mar 2022 16:53 UTC

Michael S <already5chosen@yahoo.com> writes:

> On Sunday, March 6, 2022 at 5:24:05 AM UTC+2, Tim Rentsch wrote:
>
>> Niklas Holsti <niklas...@tidorum.invalid> writes:
>>
>>> On 2022-03-05 22:22, MitchAlsup wrote:
>>>
>>>> https://www.youtube.com/watch?v=QM1iUe6IofM
>>>>
>>>> I end up agreeing with the vast majority of his points and have
>>>> always programmed in the fashion he describes.
>>>
>>> He seems to be a guy who tried to follow and believe the pure
>>> object-oriented dogma and the gurus who propound it, but then found
>>> it not to be the (whole) truth, and lapsed from the faith. Good for
>>> him.
>>>
>>> But, as for most arguments against fundamentalist (quasi-)religious
>>> doctrines, his arguments against pure object-orientation are tedious
>>> and over-elaborated. He has a shorter, later, and more concrete
>>> video showing four examples of OO programs that he rewrites into
>>> procedural form:
>>>
>>> https://youtu.be/IRTfhkiAqPw
>>>
>>> I agree with many of his suggestions, but I think he undervalues
>>> the maintainability and extensibility advantages of judicious use
>>> of classes, inheritance, and encapsulation. [...]
>>
>> His example programs are (as he himself notes) only about 200
>> lines each.
>>
>> Alan Kay has said: ten lines of Smalltalk is about the same as
>> ten lines of Pascal; but 20 pages of Smalltalk is about 50
>> pages of Pascal. And there is some amount of truth in that
>> comparison.
>
> First, if he said that it does not mean that he necessarily
> measured that.

I'm sure that Alan's comment was meant to express a general
tendency rather than specific numbers. Whether the actual number
is 30 or 40 or 50 pages of (non-object other) language doesn't
matter as much as the difference in scaling behavior. My own
experience with Smalltalk, and numerous other non-object
languages, bears out this tendency.

> Second, Standard Pascal is not your average procedural language.
> It has an unique property of being especially bad for anything
> above toy scale. That's why there are so many incompatible
> "Extended Pascal" dialects that people use in real world. So,
> comparison with Pascal looks to me like a strawman.

"Pascal" was meant as a stand-in for other Pascal-like languages,
not Standard Pascal specifically. He would have said the same
thing about C, except that at the time C was not widely known,
and Pascal was.

> Third, continuing the 2nd point, how do you expect 20 pages of
> [OOP] Java to compare against [non-OOP] Golang?
> Or against [non-OOP-subset-of] Python?
> My guess is that result would be quite different from Smalltalk vs
> Pascal and likely embarrassing for OOP proponents.

I am familiar with Java but would not call myself an expert. The
same is true of Python, and about Golang I know almost nothing.
That said, let me proceed.

Smalltalk is dynamically typed, with no type annotations or static
type checking. Java has (IIANM) a more traditional static type
system, using class-based and interface-based type checking. (I am
not familiar with Java generics). It's hard to get all the benefits
of object-oriented programming in a traditional static type system;
maybe not impossible, but certainly not trivial. If I were going to
do a comparison, I think a better choice (instead of Java) would be
Objective Caml, which has a richer type system than Java. Based on
my own experience, Objective Caml is more expressive than either
Java or Python. Again however my experience with Java and Python
is fairly limited, so take that impression with a grain of salt.

Incidentally, I do like Smalltalk, but dynamic typing is a double
edged sword. It would be interesting to see a full-blown object
system, like a complete Smalltalk system, done in Objective Caml
(which has a rich but staticly checked type system). Unfortunately
though I don't know of any such effort.

> But, then again, I heard that Alan Kay himself is a harsh critic
> of a version of OOP that started to develop around 1985 and became
> a dogma during nineties. Quite likely, more harsh than myself.

I haven't seen any of those remarks so I can't comment on them.
For the quoted statement that started this discussion, I know just
what he said because I heard him say it. I have read one later
remark of his, about object-oriented programming and C++: I
invented the term "object oriented", and I can tell you that C++ is
not what I had in mind.

Re: Any comments on:

<t0512s$upd$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24011&group=comp.arch#24011

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: m.del...@this.bitsnbites.eu (Marcus)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Mon, 7 Mar 2022 14:24:43 +0100
Organization: A noiseless patient Spider
Lines: 30
Message-ID: <t0512s$upd$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Mon, 7 Mar 2022 13:24:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="12b7af70c64a6bd31d12e34602937def";
logging-data="31533"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/XRwB+NlQK4CGIcQqUupLusYx8NDT9BA8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.5.0
Cancel-Lock: sha1:UILCBiHWBbUhpjjFW4wz3sqhTWM=
In-Reply-To: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
Content-Language: en-US
 by: Marcus - Mon, 7 Mar 2022 13:24 UTC

On 2022-03-05, MitchAlsup wrote:
> https://www.youtube.com/watch?v=QM1iUe6IofM
>
> I end up agreeing with the vast majority of his points and have always programmed in the fashion he describes.

I've only watched 15 minutes so far, but so far he seems to be pretty
much spot on IMO. Interesting video.

My own take on object orientation is:

- I use OOP to some extent, but I try to avoid the parts about
encapsulating state (which, I believe, was one of the main concerns
raised in the video). State encapsulation tends to make code much more
error prone and harder to test etc.

- C++ style OOP shines when you're making "micro-classes" (e.g. things
like complex number classes), especially when you inline everything
(i.e. have most of the code in the header file). IMO it gives you very
readable code *and* (usually) optimal machine code. Also, concepts
like constructors and getters/setters ensures that values are
initialized and mutated in a controlled manner, making it much easier
to refactor the code without having to update all sites where the
state/class/struct/type is used.

- I have still not used a Java program that does its job well.
Performance is usually horrible, and I do not think that the JVM & GC
are the primary problems, but Java simply seems to foster bad,
unwieldy architecture.

/Marcus

Re: Any comments on:

<t08jat$atu$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24070&group=comp.arch#24070

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 15:54:32 -0600
Organization: A noiseless patient Spider
Lines: 167
Message-ID: <t08jat$atu$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 8 Mar 2022 21:54:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="25b8e1a27b28772f8d884e8911613f80";
logging-data="11198"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ikXa1/qzcOqT4X4yc9Swg"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:Ct5tchZp+TespNybN1TBIQ5CI1Y=
In-Reply-To: <t0512s$upd$1@dont-email.me>
Content-Language: en-US
 by: BGB - Tue, 8 Mar 2022 21:54 UTC

On 3/7/2022 7:24 AM, Marcus wrote:
> On 2022-03-05, MitchAlsup wrote:
>> https://www.youtube.com/watch?v=QM1iUe6IofM
>>
>> I end up agreeing with the vast majority of his points and have always
>> programmed in the fashion he describes.
>
> I've only watched 15 minutes so far, but so far he seems to be pretty
> much spot on IMO. Interesting video.
>
> My own take on object orientation is:
>
> - I use OOP to some extent, but I try to avoid the parts about
>   encapsulating state (which, I believe, was one of the main concerns
>   raised in the video). State encapsulation tends to make code much more
>   error prone and harder to test etc.
>
> - C++ style OOP shines when you're making "micro-classes" (e.g. things
>   like complex number classes), especially when you inline everything
>   (i.e. have most of the code in the header file). IMO it gives you very
>   readable code *and* (usually) optimal machine code. Also, concepts
>   like constructors and getters/setters ensures that values are
>   initialized and mutated in a controlled manner, making it much easier
>   to refactor the code without having to update all sites where the
>   state/class/struct/type is used.
>

OOP can work OK, but a few weak areas:
Inheritance is very often not as good of an idea as it seems;
Over-reliance on virtual methods can be detrimental to performance;
...

But, if one rarely uses inheritance and virtual methods, many of the
claimed "advantages" of OOP (over procedural programming) largely evaporate.

In C, one can also get much the same effect by having structs with
function pointers. The syntax isn't quite as clean, but it can function
similarly.

Many C++ developers also seem to see templates as a silver bullet for
nearly any problem. They come with their own share of issues.

> - I have still not used a Java program that does its job well.
>   Performance is usually horrible, and I do not think that the JVM & GC
>   are the primary problems, but Java simply seems to foster bad,
>   unwieldy architecture.
>

The language design encourages writing code in a certain interpretation
of OOP, and makes it painful to do it any differently.

This is different from C++ which is more free-form, or C# which is not
nearly as restrictive in terms of code organization.

I have mixed feelings about a VM or GC. They "can make sense", but it
can be noted that there are many contexts where they don't make as much
sense.

One drawback of the JVM is that it can't really be used as a viable
target for running C. Some other VM design could do better here (.NET
comes close; meanwhile WASM introduces its own pile of issues despite
seemingly having "runs C and C++" as its design goal).

Similarly, trying to run Java on a "bare metal" target (such as a
microcontroller) would suck.

Ideally, we need a language design which can do adequately at both. It
could rope off class/instance objects into their own category, while
still being friendly to an efficient bare-metal implementation (and
allowing all the usual C level stuff).

It is possible that crossing the line between the class/instance system
and bare memory could be allowed, but within the confine of "there be
dragons here".

It can be noted that C# 'almost does this', or at least C# is closer to
what I am imagining than either Java or C++.

Or, sorta like C# but also a little more like C.

For bonus points, could also be cool to see a few features from Verilog,
such as exact bit-width values the ability to compose and decompose bit
vectors, ...

Someone could maybe also get extra wacky and borrow concepts like
'always' and 'initial' blocks.

always(cc) {
//triggers whenever cc becomes true
//does not depend on sequential control flow
}

initial {
//block runs at program start-up (1)
}

*1: Program startup sequence being:
Load / Zero ".bss" / ...
Initialize language runtime stuff;
Initialize all the globals which require dynamic init;
Run any 'initial' blocks in the program;
Transfer control to "main()".

I guess one other question could be if one could add asynchronous and
event-driven abstractions to a language which play nicer with multiple
cores than do more traditional approaches to multithreading (eg:
explicit thread creation).

Big issues are likely to be synchronization and efficiently moving data
between threads (mutex driven synchronization and shared memory having a
few obvious drawbacks).

One possibility could be to have a class of variables which appear sort
of like globals (from a given piece of code), but are in effect local
state to that particular "event" (in some sense, sorta like parameters
in GLSL). Spawning a new event from within a prior event would in effect
copy any overlapping state into the new event (if no new event is
spawned, this state simply disappears; state which is not copied is
discarded, and any new event state is zeroed).

Any large shared structures remain as an issue though, since these would
require keeping the state consistent.

One idea could be that we don't so much "call" into synchronized methods
directly, but rather that they queue up and put the caller on standby.
When the method call is handled (possibly in a different thread from the
caller), it then wakes the caller, which may resume execution in its own
thread.

Or, in effect, an RPC like abstraction is hidden inside what appears
like a normal method call. Potentially, getters and setters could use a
similar abstraction.

In contrast, an asynchronous method call would in effect detach the
caller from the callee, which may continue on independent of the other.
Within a synchronized object, both cases would have the behavior of
forcing sequential execution.

Maybe also have async blocks which could have a condition for when they
trigger:
async(cc) { ... }

But, which differs slightly in that control needs to reach the block
before it is created, and that its execution is one-off (once 'cc' is
true, the block executes once, or at least once for each time control
passes over the declaration of the async block).

Likely, state capture for an async block would be similar to that for a
lambda. It also seems likely also that the 'cc' mechanism would be
implemented similar to a constraint variable (modifying an input
triggers re-computation, rather than endlessly re-evaluating the
predicate to see if it has changed since the last time it was checked).

Granted, all of this would add a bit of complexity to a compiler.

....

Re: Any comments on:

<75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24071&group=comp.arch#24071

 copy link   Newsgroups: comp.arch
X-Received: by 2002:ae9:e114:0:b0:609:b256:ee5 with SMTP id g20-20020ae9e114000000b00609b2560ee5mr12213001qkm.93.1646781313742;
Tue, 08 Mar 2022 15:15:13 -0800 (PST)
X-Received: by 2002:a05:6870:f297:b0:c5:570:32da with SMTP id
u23-20020a056870f29700b000c5057032damr3841860oap.106.1646781313334; Tue, 08
Mar 2022 15:15:13 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 8 Mar 2022 15:15:13 -0800 (PST)
In-Reply-To: <t08jat$atu$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:55d2:d535:c417:7b08;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:55d2:d535:c417:7b08
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
Subject: Re: Any comments on:
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Tue, 08 Mar 2022 23:15:13 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 102
 by: MitchAlsup - Tue, 8 Mar 2022 23:15 UTC

On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
> On 3/7/2022 7:24 AM, Marcus wrote:
> > On 2022-03-05, MitchAlsup wrote:
>
> For bonus points, could also be cool to see a few features from Verilog,
> such as exact bit-width values the ability to compose and decompose bit
> vectors, ...
<
Where bit widths are essentially unlimited.....
>
> Someone could maybe also get extra wacky and borrow concepts like
> 'always' and 'initial' blocks.
>
> always(cc) {
> //triggers whenever cc becomes true
> //does not depend on sequential control flow
> }
>
> initial {
> //block runs at program start-up (1)
> }
>
> *1: Program startup sequence being:
> Load / Zero ".bss" / ...
> Initialize language runtime stuff;
> Initialize all the globals which require dynamic init;
> Run any 'initial' blocks in the program;
> Transfer control to "main()".
>
Good ideas.
>
> I guess one other question could be if one could add asynchronous and
> event-driven abstractions to a language which play nicer with multiple
> cores than do more traditional approaches to multithreading (eg:
> explicit thread creation).
>
> Big issues are likely to be synchronization and efficiently moving data
> between threads (mutex driven synchronization and shared memory having a
> few obvious drawbacks).
>
<---------------------------------------------------------------------------------------------------------------
> One possibility could be to have a class of variables which appear sort
> of like globals (from a given piece of code), but are in effect local
> state to that particular "event" (in some sense, sorta like parameters
> in GLSL). Spawning a new event from within a prior event would in effect
> copy any overlapping state into the new event (if no new event is
> spawned, this state simply disappears; state which is not copied is
> discarded, and any new event state is zeroed).
<
How is this different from ThreadLocalStore ?
<----------------------------------------------------------------------------------------------------------------
>
>
> Any large shared structures remain as an issue though, since these would
> require keeping the state consistent.
>
> One idea could be that we don't so much "call" into synchronized methods
> directly, but rather that they queue up and put the caller on standby.
<
This is like the message facility I recently put into My 66000.
<
> When the method call is handled (possibly in a different thread from the
> caller), it then wakes the caller, which may resume execution in its own
> thread.
<
Different thread, different address space, under a different Guest OS.
>
> Or, in effect, an RPC like abstraction is hidden inside what appears
> like a normal method call. Potentially, getters and setters could use a
> similar abstraction.
>
> In contrast, an asynchronous method call would in effect detach the
> caller from the callee, which may continue on independent of the other.
> Within a synchronized object, both cases would have the behavior of
> forcing sequential execution.
<
This is the Send Message end of things.
>
> Maybe also have async blocks which could have a condition for when they
> trigger:
> async(cc) { ... }
>
> But, which differs slightly in that control needs to reach the block
> before it is created, and that its execution is one-off (once 'cc' is
> true, the block executes once, or at least once for each time control
> passes over the declaration of the async block).
>
> Likely, state capture for an async block would be similar to that for a
> lambda. It also seems likely also that the 'cc' mechanism would be
> implemented similar to a constraint variable (modifying an input
> triggers re-computation, rather than endlessly re-evaluating the
> predicate to see if it has changed since the last time it was checked).
>
>
> Granted, all of this would add a bit of complexity to a compiler.
>
One concept I have been thinking about recently is a virtual core::
What would happen to applications and OSs if they could pretend
that there was an essentially unlimited number of cores (say more
than 1024 as a minimum but scalable at least to the 16M cores level.)
And instead of cores looking for work, work turns around and looks
for cores......
> ...

Re: Any comments on:

<t08qij$vvi$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24072&group=comp.arch#24072

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 15:58:11 -0800
Organization: A noiseless patient Spider
Lines: 72
Message-ID: <t08qij$vvi$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 8 Mar 2022 23:58:11 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="5f542763a2ddb2adf56facc010c4f50a";
logging-data="32754"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+cWFjvCeEmwSVaHssf7tvE"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:+JXV+9MJYqPpiRGXytC9IfTBEDs=
In-Reply-To: <75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
Content-Language: en-US
 by: Ivan Godard - Tue, 8 Mar 2022 23:58 UTC

On 3/8/2022 3:15 PM, MitchAlsup wrote:
> On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
>> On 3/7/2022 7:24 AM, Marcus wrote:
>>> On 2022-03-05, MitchAlsup wrote:
>>
>> For bonus points, could also be cool to see a few features from Verilog,
>> such as exact bit-width values the ability to compose and decompose bit
>> vectors, ...
> <
> Where bit widths are essentially unlimited.....
>>
>> Someone could maybe also get extra wacky and borrow concepts like
>> 'always' and 'initial' blocks.
>>
>> always(cc) {
>> //triggers whenever cc becomes true
>> //does not depend on sequential control flow
>> }
>>
>> initial {
>> //block runs at program start-up (1)
>> }
>>
>> *1: Program startup sequence being:
>> Load / Zero ".bss" / ...
>> Initialize language runtime stuff;
>> Initialize all the globals which require dynamic init;
>> Run any 'initial' blocks in the program;
>> Transfer control to "main()".
>>
> Good ideas.
>>
>> I guess one other question could be if one could add asynchronous and
>> event-driven abstractions to a language which play nicer with multiple
>> cores than do more traditional approaches to multithreading (eg:
>> explicit thread creation).
>>
>> Big issues are likely to be synchronization and efficiently moving data
>> between threads (mutex driven synchronization and shared memory having a
>> few obvious drawbacks).
>>
> <---------------------------------------------------------------------------------------------------------------
>> One possibility could be to have a class of variables which appear sort
>> of like globals (from a given piece of code), but are in effect local
>> state to that particular "event" (in some sense, sorta like parameters
>> in GLSL). Spawning a new event from within a prior event would in effect
>> copy any overlapping state into the new event (if no new event is
>> spawned, this state simply disappears; state which is not copied is
>> discarded, and any new event state is zeroed).
> <
> How is this different from ThreadLocalStore ?
> <----------------------------------------------------------------------------------------------------------------
>>
>>
>> Any large shared structures remain as an issue though, since these would
>> require keeping the state consistent.
>>
>> One idea could be that we don't so much "call" into synchronized methods
>> directly, but rather that they queue up and put the caller on standby.
> <
> This is like the message facility I recently put into My 66000.

What I didn't get from your message description was why it had to be
cross-thread. One frequently wants to switch protection environments
with the ability to pass arguments across the switching, but why not do
that in the current thread, so you don't have to worry about blocking
and queuing? If it really is a message that really is intended for some
other thread, then you can switch into the domain of the target thread
and software can do all the waiting and queuing with much more
flexibility than baking it into hardware.

Please expand.

Re: Any comments on:

<80644d1b-9b03-4c63-aab8-fbfd09bd5dd7n@googlegroups.com>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24073&group=comp.arch#24073

 copy link   Newsgroups: comp.arch
X-Received: by 2002:a37:9746:0:b0:61f:ea7b:a488 with SMTP id z67-20020a379746000000b0061fea7ba488mr12407453qkd.618.1646789220453;
Tue, 08 Mar 2022 17:27:00 -0800 (PST)
X-Received: by 2002:a05:6808:1149:b0:2d9:a01a:48a4 with SMTP id
u9-20020a056808114900b002d9a01a48a4mr4572829oiu.239.1646789220124; Tue, 08
Mar 2022 17:27:00 -0800 (PST)
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.misty.com!border2.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 8 Mar 2022 17:26:59 -0800 (PST)
In-Reply-To: <t08qij$vvi$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:682f:1a71:85fb:5088;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:682f:1a71:85fb:5088
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me> <75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
<t08qij$vvi$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <80644d1b-9b03-4c63-aab8-fbfd09bd5dd7n@googlegroups.com>
Subject: Re: Any comments on:
From: MitchAl...@aol.com (MitchAlsup)
Injection-Date: Wed, 09 Mar 2022 01:27:00 +0000
Content-Type: text/plain; charset="UTF-8"
Lines: 89
 by: MitchAlsup - Wed, 9 Mar 2022 01:26 UTC

On Tuesday, March 8, 2022 at 5:58:14 PM UTC-6, Ivan Godard wrote:
> On 3/8/2022 3:15 PM, MitchAlsup wrote:
> > On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
> >> On 3/7/2022 7:24 AM, Marcus wrote:
> >>> On 2022-03-05, MitchAlsup wrote:
> >>
> >> For bonus points, could also be cool to see a few features from Verilog,
> >> such as exact bit-width values the ability to compose and decompose bit
> >> vectors, ...
> > <
> > Where bit widths are essentially unlimited.....
> >>
> >> Someone could maybe also get extra wacky and borrow concepts like
> >> 'always' and 'initial' blocks.
> >>
> >> always(cc) {
> >> //triggers whenever cc becomes true
> >> //does not depend on sequential control flow
> >> }
> >>
> >> initial {
> >> //block runs at program start-up (1)
> >> }
> >>
> >> *1: Program startup sequence being:
> >> Load / Zero ".bss" / ...
> >> Initialize language runtime stuff;
> >> Initialize all the globals which require dynamic init;
> >> Run any 'initial' blocks in the program;
> >> Transfer control to "main()".
> >>
> > Good ideas.
> >>
> >> I guess one other question could be if one could add asynchronous and
> >> event-driven abstractions to a language which play nicer with multiple
> >> cores than do more traditional approaches to multithreading (eg:
> >> explicit thread creation).
> >>
> >> Big issues are likely to be synchronization and efficiently moving data
> >> between threads (mutex driven synchronization and shared memory having a
> >> few obvious drawbacks).
> >>
> > <---------------------------------------------------------------------------------------------------------------
> >> One possibility could be to have a class of variables which appear sort
> >> of like globals (from a given piece of code), but are in effect local
> >> state to that particular "event" (in some sense, sorta like parameters
> >> in GLSL). Spawning a new event from within a prior event would in effect
> >> copy any overlapping state into the new event (if no new event is
> >> spawned, this state simply disappears; state which is not copied is
> >> discarded, and any new event state is zeroed).
> > <
> > How is this different from ThreadLocalStore ?
> > <----------------------------------------------------------------------------------------------------------------
> >>
> >>
> >> Any large shared structures remain as an issue though, since these would
> >> require keeping the state consistent.
> >>
> >> One idea could be that we don't so much "call" into synchronized methods
> >> directly, but rather that they queue up and put the caller on standby.
> > <
> > This is like the message facility I recently put into My 66000.
<
> What I didn't get from your message description was why it had to be
> cross-thread. One frequently wants to switch protection environments
> with the ability to pass arguments across the switching, but why not do
> that in the current thread, so you don't have to worry about blocking
> and queuing?
<
If you want to stay in the same thread, you use a CALL instruction.
If you want to cross to a different thread, you use the MSG instruction.
<
Curiously; the receiver can be compiled into the same instructions--
without necessarily knowing if the call was local or remote--he receives
control, does something with it, and then returns control back--just like
a regular subroutine.
<
< If it really is a message that really is intended for some
> other thread, then you can switch into the domain of the target thread
> and software can do all the waiting and queuing with much more
> flexibility than baking it into hardware.
<
There are no instructions to perform context switching. indeed, context
switching is not done in a CPU/core/whatever you want to call them now.
Cores "get" context switched; they do not context switch to another thread.
Work looks for cores, cores do not look for work.
>
> Please expand.
<
A lot of this falls under NYF right now.

Re: Any comments on:

<t0942v$rja$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24074&group=comp.arch#24074

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 20:40:26 -0600
Organization: A noiseless patient Spider
Lines: 216
Message-ID: <t0942v$rja$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Mar 2022 02:40:31 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8df13030d16cd666421288ad29864a11";
logging-data="28266"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Uc2YK4Y568h0vrKYNtEtW"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:pK3qd3ycqU48g6spOFqgrmHTK7Y=
In-Reply-To: <75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
Content-Language: en-US
 by: BGB - Wed, 9 Mar 2022 02:40 UTC

On 3/8/2022 5:15 PM, MitchAlsup wrote:
> On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
>> On 3/7/2022 7:24 AM, Marcus wrote:
>>> On 2022-03-05, MitchAlsup wrote:
>>
>> For bonus points, could also be cool to see a few features from Verilog,
>> such as exact bit-width values the ability to compose and decompose bit
>> vectors, ...
> <
> Where bit widths are essentially unlimited.....

Granted.

I would assume this to be implemented on top of something like a
"_BitInt(n)" type, where the underlying storage picks one of the basic
machine-supported types, or uses a large variable-size number for large
types.

There might be an implementation limit, say, 64k bits or similar, but we
can assume for sake of argument that it is large enough to be mostly
ignored.

Unlike _BitInt, the compiler would be expected to remember the exact
number of bits the type was declared as, and (like in Verilator) enforce
width-checks and similar for exact-width integer types.

>>
>> Someone could maybe also get extra wacky and borrow concepts like
>> 'always' and 'initial' blocks.
>>
>> always(cc) {
>> //triggers whenever cc becomes true
>> //does not depend on sequential control flow
>> }
>>
>> initial {
>> //block runs at program start-up (1)
>> }
>>
>> *1: Program startup sequence being:
>> Load / Zero ".bss" / ...
>> Initialize language runtime stuff;
>> Initialize all the globals which require dynamic init;
>> Run any 'initial' blocks in the program;
>> Transfer control to "main()".
>>
> Good ideas.
>>
>> I guess one other question could be if one could add asynchronous and
>> event-driven abstractions to a language which play nicer with multiple
>> cores than do more traditional approaches to multithreading (eg:
>> explicit thread creation).
>>
>> Big issues are likely to be synchronization and efficiently moving data
>> between threads (mutex driven synchronization and shared memory having a
>> few obvious drawbacks).
>>
> <---------------------------------------------------------------------------------------------------------------
>> One possibility could be to have a class of variables which appear sort
>> of like globals (from a given piece of code), but are in effect local
>> state to that particular "event" (in some sense, sorta like parameters
>> in GLSL). Spawning a new event from within a prior event would in effect
>> copy any overlapping state into the new event (if no new event is
>> spawned, this state simply disappears; state which is not copied is
>> discarded, and any new event state is zeroed).
> <
> How is this different from ThreadLocalStore ?
> <----------------------------------------------------------------------------------------------------------------

TLS is attached to a specific thread of execution, rather than to an
event. Multiple events may trigger within the same logical thread, but
will each have their own state, which would follow along with the path
in which events are spawned.

These would be semantically distinct from either lexical or dynamic
scoping, in that they follow control flow (like dynamic bindings), but
also function according to capture (more like lexical bindings within
lambdas).

One could also have dynamic variables though, and observe that when one
has these, they may become (in effect) semantically equivalent to a
superset of TLS variables.

The event-scoped variables would become equivalent to TLS though, if one
assumes that event spawning is semantically equivalent for forking a
thread, and that the lifetime of such a thread is equivalent to that of
the event (or, in effect the event mechanism is itself implemented using
short-lived threads).

One other difference is that traditionally, each thread (or green
thread) is given its own stack, whereas an event would not necessarily
have its own stack (but could inherit a stack from the parent thread,
which is given back to the parent once the event finishes or when
control transfers to a new event).

So, depends a lot on how things are implemented (and whether it is
cheaper to spawn and destroy micro-threads or to move over to an ABI
based around continuation-passing-style or similar).

>>
>>
>> Any large shared structures remain as an issue though, since these would
>> require keeping the state consistent.
>>
>> One idea could be that we don't so much "call" into synchronized methods
>> directly, but rather that they queue up and put the caller on standby.
> <
> This is like the message facility I recently put into My 66000.
> <

This is also a feature one of my older languages had, but was dropped
when I moved its descendant over to a more simplified (and more Java
like) execution model.

This was along with moving the scoping model from being dynamically
mutable, over to a statically determined scope (runtime mutable scope is
either slow, or the complexity can become a little nightmarish).

>> When the method call is handled (possibly in a different thread from the
>> caller), it then wakes the caller, which may resume execution in its own
>> thread.
> <
> Different thread, different address space, under a different Guest OS.

This is possible.

I was imagining within a single address space, rather than necessarily a
generalized RPC mechanism. Granted, depending on how it is implemented,
it isn't too far of a stretch to generalize this to an RPC.

It would mostly involve a mechanism to add a request from the current
request to a queue associated with the target and (if needed) to direct
attention to this target.

It is likely in this case that the current thread would stop execution
and transfer control to another thread, being "woken up" again once the
target call completes.

How to best pull this off at the ABI level is "to be determined", one
likely option is that it fallows the normal ABI initially, but that the
function or method call is actually to a wrapper (which implements the
mechanism in question). This being (likely) cheaper than a more complex
option, such as compiling the program to be built in terms of
continuation-passing-style (CPS).

Granted, if I felt there was a strong use-case, I could probably define
a CPS based ABI. Main drawback is that a CPS ABI would almost invariably
perform worse than a call-stack ABI, since one effectively allocates and
frees call frames rather than adjusting the stack pointer.

One open question then, would be rather one would use a separate IDL (as
in DCOM or CORBA), or make use of the language-level types and
declarations instead.

Typically, separate address space does require an ability to serialize
and de-serialize data (and identify objects by handle rather than by
address), which in turn requires type metadata and reflection.

This is doable, though (indirectly) would mostly leave traditional C out
of the RPC party.

Another simplifying assumption would be to assume using a dynamic
type-system across the RPC interface (which may map to/from the static
typesystem on either end).

>>
>> Or, in effect, an RPC like abstraction is hidden inside what appears
>> like a normal method call. Potentially, getters and setters could use a
>> similar abstraction.
>>
>> In contrast, an asynchronous method call would in effect detach the
>> caller from the callee, which may continue on independent of the other.
>> Within a synchronized object, both cases would have the behavior of
>> forcing sequential execution.
> <
> This is the Send Message end of things.
>>
>> Maybe also have async blocks which could have a condition for when they
>> trigger:
>> async(cc) { ... }
>>
>> But, which differs slightly in that control needs to reach the block
>> before it is created, and that its execution is one-off (once 'cc' is
>> true, the block executes once, or at least once for each time control
>> passes over the declaration of the async block).
>>
>> Likely, state capture for an async block would be similar to that for a
>> lambda. It also seems likely also that the 'cc' mechanism would be
>> implemented similar to a constraint variable (modifying an input
>> triggers re-computation, rather than endlessly re-evaluating the
>> predicate to see if it has changed since the last time it was checked).
>>
>>
>> Granted, all of this would add a bit of complexity to a compiler.
>>
> One concept I have been thinking about recently is a virtual core::
> What would happen to applications and OSs if they could pretend
> that there was an essentially unlimited number of cores (say more
> than 1024 as a minimum but scalable at least to the 16M cores level.)
> And instead of cores looking for work, work turns around and looks
> for cores......


Click here to read the complete article
Re: Any comments on:

<t095rg$5dj$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24075&group=comp.arch#24075

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 19:10:40 -0800
Organization: A noiseless patient Spider
Lines: 28
Message-ID: <t095rg$5dj$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
<t0942v$rja$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Mar 2022 03:10:40 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="5f542763a2ddb2adf56facc010c4f50a";
logging-data="5555"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18itL+B8Dv8yWDUslYkWOPM"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:9MvqAw8BLQoCurlTDvFZRK23H50=
In-Reply-To: <t0942v$rja$1@dont-email.me>
Content-Language: en-US
 by: Ivan Godard - Wed, 9 Mar 2022 03:10 UTC

On 3/8/2022 6:40 PM, BGB wrote:
> On 3/8/2022 5:15 PM, MitchAlsup wrote:
>> On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
>>> On 3/7/2022 7:24 AM, Marcus wrote:
>>>> On 2022-03-05, MitchAlsup wrote:
>>>
>>> For bonus points, could also be cool to see a few features from Verilog,
>>> such as exact bit-width values the ability to compose and decompose bit
>>> vectors, ...
>> <
>> Where bit widths are essentially unlimited.....
>
> Granted.
>
> I would assume this to be implemented on top of something like a
> "_BitInt(n)" type, where the underlying storage picks one of the basic
> machine-supported types, or uses a large variable-size number for large
> types.
>
> There might be an implementation limit, say, 64k bits or similar, but we
> can assume for sake of argument that it is large enough to be mostly
> ignored.
>
> Unlike _BitInt, the compiler would be expected to remember the exact
> number of bits the type was declared as, and (like in Verilator) enforce
> width-checks and similar for exact-width integer types.

Wasn't this the 432?

Re: Any comments on:

<t09722$d7f$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24076&group=comp.arch#24076

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 19:31:14 -0800
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <t09722$d7f$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 03:31:15 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="85b0e470e1095c54d053a92bbfa38654";
logging-data="13551"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+t0O1PbAa1Coy/V3aH1Nu1Y0K97JfjcJo="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.2
Cancel-Lock: sha1:1Wp/f7iaUrdFJInHCVbTYQAVFgc=
In-Reply-To: <t08jat$atu$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Wed, 9 Mar 2022 03:31 UTC

On 3/8/2022 1:54 PM, BGB wrote:

snip

>
> initial {
>   //block runs at program start-up (1)
> }
>
> *1: Program startup sequence being:
>   Load / Zero ".bss" / ...
>   Initialize language runtime stuff;
>   Initialize all the globals which require dynamic init;
>   Run any 'initial' blocks in the program;
>   Transfer control to "main()".
>

How is this different from or better than just putting whatever is in
the "initial" block at the start of main (), like programmers have been
doing for decades?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Any comments on:

<t098dq$k1s$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24077&group=comp.arch#24077

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: iva...@millcomputing.com (Ivan Godard)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 19:54:34 -0800
Organization: A noiseless patient Spider
Lines: 25
Message-ID: <t098dq$k1s$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 03:54:35 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="5f542763a2ddb2adf56facc010c4f50a";
logging-data="20540"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+Hn+jnyoswYnECTruttVFl"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:CsZXoP+eXfB5aV7pNS0CATZFh4c=
In-Reply-To: <t09722$d7f$1@dont-email.me>
Content-Language: en-US
 by: Ivan Godard - Wed, 9 Mar 2022 03:54 UTC

On 3/8/2022 7:31 PM, Stephen Fuld wrote:
> On 3/8/2022 1:54 PM, BGB wrote:
>
> snip
>
>>
>> initial {
>>    //block runs at program start-up (1)
>> }
>>
>> *1: Program startup sequence being:
>>    Load / Zero ".bss" / ...
>>    Initialize language runtime stuff;
>>    Initialize all the globals which require dynamic init;
>>    Run any 'initial' blocks in the program;
>>    Transfer control to "main()".
>>
>
> How is this different from or better than just putting whatever is in
> the "initial" block at the start of main (), like programmers have been
> doing for decades?
>
>

There's pre-main stuff that is done by __start

Re: Any comments on:

<t09aqf$14m$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24078&group=comp.arch#24078

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 22:35:22 -0600
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <t09aqf$14m$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<75bfc254-88be-43b1-ab08-fb610d1652ben@googlegroups.com>
<t0942v$rja$1@dont-email.me> <t095rg$5dj$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Wed, 9 Mar 2022 04:35:27 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8df13030d16cd666421288ad29864a11";
logging-data="1174"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/B7eqsBa/htfM9ixQHjnVl"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:JgxvVVGJFdyniR2wBL5hEkTOl+U=
In-Reply-To: <t095rg$5dj$1@dont-email.me>
Content-Language: en-US
 by: BGB - Wed, 9 Mar 2022 04:35 UTC

On 3/8/2022 9:10 PM, Ivan Godard wrote:
> On 3/8/2022 6:40 PM, BGB wrote:
>> On 3/8/2022 5:15 PM, MitchAlsup wrote:
>>> On Tuesday, March 8, 2022 at 3:54:41 PM UTC-6, BGB wrote:
>>>> On 3/7/2022 7:24 AM, Marcus wrote:
>>>>> On 2022-03-05, MitchAlsup wrote:
>>>>
>>>> For bonus points, could also be cool to see a few features from
>>>> Verilog,
>>>> such as exact bit-width values the ability to compose and decompose bit
>>>> vectors, ...
>>> <
>>> Where bit widths are essentially unlimited.....
>>
>> Granted.
>>
>> I would assume this to be implemented on top of something like a
>> "_BitInt(n)" type, where the underlying storage picks one of the basic
>> machine-supported types, or uses a large variable-size number for
>> large types.
>>
>> There might be an implementation limit, say, 64k bits or similar, but
>> we can assume for sake of argument that it is large enough to be
>> mostly ignored.
>>
>> Unlike _BitInt, the compiler would be expected to remember the exact
>> number of bits the type was declared as, and (like in Verilator)
>> enforce width-checks and similar for exact-width integer types.
>
> Wasn't this the 432?

?...

iAPX 432 was an ISA.

This would be a compiler/language feature implemented mostly on terms of
normal ALU ops.

In BGBCC. I have already added _BitInt, which works similar to the
former case, but may pad the types up to a larger number of bits, and
does not remember the exact bit width.

The idea for an exact bit width type is that, while the storage is
padded, the compiler would be expected to make it behave as-if it were
the exact number of bits.

While its utility would be a little debatable for plain CPU side tasks,
it would be a bit more relevant for HLS style use-cases, where the
compiler could decide to run some (or all) of the logic on an FPGA.

But, for this, ideally one could have a language which makes sense both
on the CPU and when run on the FPGA (as opposed to a language which
works fairly well on one target and 'sucks real hard' on the other).

Re: Any comments on:

<t09bl8$5hf$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24079&group=comp.arch#24079

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 22:49:39 -0600
Organization: A noiseless patient Spider
Lines: 38
Message-ID: <t09bl8$5hf$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 04:49:44 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8df13030d16cd666421288ad29864a11";
logging-data="5679"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19+ABnn9F4J7FlYEmUImxev"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:Uzb8un1NRN4L9ZUrbe33sYd8PeU=
In-Reply-To: <t09722$d7f$1@dont-email.me>
Content-Language: en-US
 by: BGB - Wed, 9 Mar 2022 04:49 UTC

On 3/8/2022 9:31 PM, Stephen Fuld wrote:
> On 3/8/2022 1:54 PM, BGB wrote:
>
> snip
>
>>
>> initial {
>>    //block runs at program start-up (1)
>> }
>>
>> *1: Program startup sequence being:
>>    Load / Zero ".bss" / ...
>>    Initialize language runtime stuff;
>>    Initialize all the globals which require dynamic init;
>>    Run any 'initial' blocks in the program;
>>    Transfer control to "main()".
>>
>
> How is this different from or better than just putting whatever is in
> the "initial" block at the start of main (), like programmers have been
> doing for decades?
>

The person writing "main()" does not need to put in calls to the
"Init()" functions, they don't even need to know they exist.

They can also rely on the init logic having run, rather than having to
add "check and init" code that would otherwise be needed to deal with
code where the user is not expected to call some "Init()" functions in
advance (but, then one is potentially wasting time at runtime by
checking whether or not the library code has already been initialized).

The actual implementation overhead wouldn't be that large as the
compiler may already need to do something like this to perform some
non-trivial global variable initialization. This is because programs can
sometimes initialize global variables with expressions that are not
really able to be evaluated at compile time.

Re: Any comments on:

<t09clp$b1m$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24080&group=comp.arch#24080

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 21:07:03 -0800
Organization: A noiseless patient Spider
Lines: 49
Message-ID: <t09clp$b1m$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me> <t09bl8$5hf$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 05:07:05 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="85b0e470e1095c54d053a92bbfa38654";
logging-data="11318"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/up3HscEY3CVOCV5d3VzQtCQJU6ogsyU0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.2
Cancel-Lock: sha1:ErxavjE/JtaDRF9ICGi5oozEf0k=
In-Reply-To: <t09bl8$5hf$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Wed, 9 Mar 2022 05:07 UTC

On 3/8/2022 8:49 PM, BGB wrote:
> On 3/8/2022 9:31 PM, Stephen Fuld wrote:
>> On 3/8/2022 1:54 PM, BGB wrote:
>>
>> snip
>>
>>>
>>> initial {
>>>    //block runs at program start-up (1)
>>> }
>>>
>>> *1: Program startup sequence being:
>>>    Load / Zero ".bss" / ...
>>>    Initialize language runtime stuff;
>>>    Initialize all the globals which require dynamic init;
>>>    Run any 'initial' blocks in the program;
>>>    Transfer control to "main()".
>>>
>>
>> How is this different from or better than just putting whatever is in
>> the "initial" block at the start of main (), like programmers have
>> been doing for decades?
>>
>
> The person writing "main()" does not need to put in calls to the
> "Init()" functions, they don't even need to know they exist.
>
> They can also rely on the init logic having run, rather than having to
> add "check and init" code that would otherwise be needed to deal with
> code where the user is not expected to call some "Init()" functions in
> advance (but, then one is potentially wasting time at runtime by
> checking whether or not the library code has already been initialized).
>
>
> The actual implementation overhead wouldn't be that large as the
> compiler may already need to do something like this to perform some
> non-trivial global variable initialization. This is because programs can
> sometimes initialize global variables with expressions that are not
> really able to be evaluated at compile time.

I am used to compilers that automatically add code to the start of the
main program to do the "standard" stuff like initializing any language
runtime stuff, and presumably any complex global initialization, so that
argument goes away. Do today's compilers not do that?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Any comments on:

<t09cnu$b1m$2@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24081&group=comp.arch#24081

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 21:08:13 -0800
Organization: A noiseless patient Spider
Lines: 34
Message-ID: <t09cnu$b1m$2@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me> <t098dq$k1s$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 05:08:14 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="85b0e470e1095c54d053a92bbfa38654";
logging-data="11318"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18B3JFqg0drU/QjaDwBzOiJ4Ib1mlUXdY8="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.2
Cancel-Lock: sha1:MowKQN0WldaDpn7U4NB9ePRc3WQ=
In-Reply-To: <t098dq$k1s$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Wed, 9 Mar 2022 05:08 UTC

On 3/8/2022 7:54 PM, Ivan Godard wrote:
> On 3/8/2022 7:31 PM, Stephen Fuld wrote:
>> On 3/8/2022 1:54 PM, BGB wrote:
>>
>> snip
>>
>>>
>>> initial {
>>>    //block runs at program start-up (1)
>>> }
>>>
>>> *1: Program startup sequence being:
>>>    Load / Zero ".bss" / ...
>>>    Initialize language runtime stuff;
>>>    Initialize all the globals which require dynamic init;
>>>    Run any 'initial' blocks in the program;
>>>    Transfer control to "main()".
>>>
>>
>> How is this different from or better than just putting whatever is in
>> the "initial" block at the start of main (), like programmers have
>> been doing for decades?
>>
>>
>
> There's pre-main stuff that is done by __start

Agreed. But can't the compiler just put in the code to do that?

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Re: Any comments on:

<t09gqn$2u0$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24082&group=comp.arch#24082

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: cr88...@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Wed, 9 Mar 2022 00:17:53 -0600
Organization: A noiseless patient Spider
Lines: 99
Message-ID: <t09gqn$2u0$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me> <t09bl8$5hf$1@dont-email.me>
<t09clp$b1m$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 06:17:59 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="8df13030d16cd666421288ad29864a11";
logging-data="3008"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/D+bCFofoyj2AMuTOd1YWN"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.1
Cancel-Lock: sha1:vP6tj6vBMO7903hzGuDoFjnfh5o=
In-Reply-To: <t09clp$b1m$1@dont-email.me>
Content-Language: en-US
 by: BGB - Wed, 9 Mar 2022 06:17 UTC

On 3/8/2022 11:07 PM, Stephen Fuld wrote:
> On 3/8/2022 8:49 PM, BGB wrote:
>> On 3/8/2022 9:31 PM, Stephen Fuld wrote:
>>> On 3/8/2022 1:54 PM, BGB wrote:
>>>
>>> snip
>>>
>>>>
>>>> initial {
>>>>    //block runs at program start-up (1)
>>>> }
>>>>
>>>> *1: Program startup sequence being:
>>>>    Load / Zero ".bss" / ...
>>>>    Initialize language runtime stuff;
>>>>    Initialize all the globals which require dynamic init;
>>>>    Run any 'initial' blocks in the program;
>>>>    Transfer control to "main()".
>>>>
>>>
>>> How is this different from or better than just putting whatever is in
>>> the "initial" block at the start of main (), like programmers have
>>> been doing for decades?
>>>
>>
>> The person writing "main()" does not need to put in calls to the
>> "Init()" functions, they don't even need to know they exist.
>>
>> They can also rely on the init logic having run, rather than having to
>> add "check and init" code that would otherwise be needed to deal with
>> code where the user is not expected to call some "Init()" functions in
>> advance (but, then one is potentially wasting time at runtime by
>> checking whether or not the library code has already been initialized).
>>
>>
>> The actual implementation overhead wouldn't be that large as the
>> compiler may already need to do something like this to perform some
>> non-trivial global variable initialization. This is because programs
>> can sometimes initialize global variables with expressions that are
>> not really able to be evaluated at compile time.
>
> I am used to compilers that automatically add code to the start of the
> main program to do the "standard" stuff like initializing any language
> runtime stuff, and presumably any complex global initialization, so that
> argument goes away.  Do today's compilers not do that?
>
>

Usually, IME, it is something like:
First, loader loads the binary, ...
Entry point points to a function with a name like '__start' or similar,
loader jumps to this address;
This does some very basic setup, and then zeroes '.bss' and similar;
The __start function does basic stuff to initialize the C library, such
as setting up malloc, setting up stdin/stdout, ...
May also do other things, like splitting up the argument list and
environment variables;
It may call another function, such as '__init' (or '__init_array') or
similar, which may call other functions from a list built at link time;
After all this, __start() calls main();
If main() returns, __start() calls _exit() or similar.

When compiling a program, compiler might do something like:
int foo_global; //no initalizer, put it in '.bss'
int bar_global=3*5; //simple constant, put it in '.data'
int baz_global=&bar_global-&foo_global; //oh no

In some great wisdom, the compilers are expected to accept expressions
like the latter, and "make it work", but there is a problem here:
We don't necessarily know the answer when first compiling the program,
and it may not be known at link time either.

So, the compiler may generate a small function whose sole purpose is to
calculate the value during program startup, and store it to the
variable. During linking, the linker may put a pointer to this function
in an linker-generated array named something like "__init_array_start"
or "__preinit_array_start" or similar.

These are also apparently used for initializing various stuff in C++ and
similar as well.

....

In this case, something like:
initial {
... stuff ...
}

Would basically get transformed into a function like:
void __init_ab69c1234() //basically, a "gensym'ed" name
{
... stuff ...
}

Which would also be added to "__init_array_start" by the linker.

Re: Any comments on:

<t09l11$18n$1@dont-email.me>

 copy mid

https://www.novabbs.com/devel/article-flat.php?id=24084&group=comp.arch#24084

 copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail
From: sfu...@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Any comments on:
Date: Tue, 8 Mar 2022 23:29:35 -0800
Organization: A noiseless patient Spider
Lines: 117
Message-ID: <t09l11$18n$1@dont-email.me>
References: <8b7379c0-275a-44de-b1a3-439bf9efd210n@googlegroups.com>
<t0512s$upd$1@dont-email.me> <t08jat$atu$1@dont-email.me>
<t09722$d7f$1@dont-email.me> <t09bl8$5hf$1@dont-email.me>
<t09clp$b1m$1@dont-email.me> <t09gqn$2u0$1@dont-email.me>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Wed, 9 Mar 2022 07:29:37 -0000 (UTC)
Injection-Info: reader02.eternal-september.org; posting-host="5487fd3a4e5f2061c52f615478bb464e";
logging-data="1303"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19kN1TnngUeS3uvwFDUvw/PU2f5egIRvyU="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101
Thunderbird/91.6.2
Cancel-Lock: sha1:vE2sjmM9ECsdRvMneOvV2IRXfMc=
In-Reply-To: <t09gqn$2u0$1@dont-email.me>
Content-Language: en-US
 by: Stephen Fuld - Wed, 9 Mar 2022 07:29 UTC

On 3/8/2022 10:17 PM, BGB wrote:
> On 3/8/2022 11:07 PM, Stephen Fuld wrote:
>> On 3/8/2022 8:49 PM, BGB wrote:
>>> On 3/8/2022 9:31 PM, Stephen Fuld wrote:
>>>> On 3/8/2022 1:54 PM, BGB wrote:
>>>>
>>>> snip
>>>>
>>>>>
>>>>> initial {
>>>>>    //block runs at program start-up (1)
>>>>> }
>>>>>
>>>>> *1: Program startup sequence being:
>>>>>    Load / Zero ".bss" / ...
>>>>>    Initialize language runtime stuff;
>>>>>    Initialize all the globals which require dynamic init;
>>>>>    Run any 'initial' blocks in the program;
>>>>>    Transfer control to "main()".
>>>>>
>>>>
>>>> How is this different from or better than just putting whatever is
>>>> in the "initial" block at the start of main (), like programmers
>>>> have been doing for decades?
>>>>
>>>
>>> The person writing "main()" does not need to put in calls to the
>>> "Init()" functions, they don't even need to know they exist.
>>>
>>> They can also rely on the init logic having run, rather than having
>>> to add "check and init" code that would otherwise be needed to deal
>>> with code where the user is not expected to call some "Init()"
>>> functions in advance (but, then one is potentially wasting time at
>>> runtime by checking whether or not the library code has already been
>>> initialized).
>>>
>>>
>>> The actual implementation overhead wouldn't be that large as the
>>> compiler may already need to do something like this to perform some
>>> non-trivial global variable initialization. This is because programs
>>> can sometimes initialize global variables with expressions that are
>>> not really able to be evaluated at compile time.
>>
>> I am used to compilers that automatically add code to the start of the
>> main program to do the "standard" stuff like initializing any language
>> runtime stuff, and presumably any complex global initialization, so
>> that argument goes away.  Do today's compilers not do that?
>>
>>
>
> Usually, IME, it is something like:
> First, loader loads the binary, ...
> Entry point points to a function with a name like '__start' or similar,
> loader jumps to this address;
> This does some very basic setup, and then zeroes '.bss' and similar;
> The __start function does basic stuff to initialize the C library, such
> as setting up malloc, setting up stdin/stdout, ...
> May also do other things, like splitting up the argument list and
> environment variables;
> It may call another function, such as '__init' (or '__init_array') or
> similar, which may call other functions from a list built at link time;
> After all this, __start() calls main();
> If main() returns, __start() calls _exit() or similar.
>
>
> When compiling a program, compiler might do something like:
>   int foo_global;  //no initalizer, put it in '.bss'
>   int bar_global=3*5;  //simple constant, put it in '.data'
>   int baz_global=&bar_global-&foo_global;   //oh no
>
> In some great wisdom, the compilers are expected to accept expressions
> like the latter, and "make it work", but there is a problem here:
> We don't necessarily know the answer when first compiling the program,
> and it may not be known at link time either.
>
> So, the compiler may generate a small function whose sole purpose is to
> calculate the value during program startup, and store it to the
> variable. During linking, the linker may put a pointer to this function
> in an linker-generated array named something like "__init_array_start"
> or "__preinit_array_start" or similar.
>
> These are also apparently used for initializing various stuff in C++ and
> similar as well.

That all makes sense.

>
> ...
>
>
>
> In this case, something like:
>   initial {
>      ... stuff ...
>   }
>
> Would basically get transformed into a function like:
>   void __init_ab69c1234()  //basically, a "gensym'ed" name
>   {
>      ... stuff ...
>   }
>
> Which would also be added to "__init_array_start" by the linker.
>

So, let me get back to my original question. Why do you need this
separate "Initialize" block, when the compiler automatically does some
of the work, and the programmer can simply put whatever else would be
done in that block as the first few statements in "main"? the "Initial"
statement just seems to me to be extra syntax that accomplishes nothing.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

Pages:12
server_pubkey.txt

rocksolid light 0.9.7
clearnet tor