Rocksolid Light

Welcome to Rocksolid Light

mail  files  register  newsreader  groups  login

Message-ID:  

Life is a game. Money is how we keep score. -- Ted Turner


devel / comp.arch / Re: Misc: Design tradeoffs in virtual memory systems...

SubjectAuthor
* Misc: Design tradeoffs in virtual memory systems...BGB
+* Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|+- Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|+* Re: Misc: Design tradeoffs in virtual memory systems...BGB
||+* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|||`* Re: Misc: Design tradeoffs in virtual memory systems...BGB
||| `- Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
||`* Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| +* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |`* Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| | `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  +* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |+* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||`* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  || `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||  +* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  |+- Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||  |+* Re: Misc: Design tradeoffs in virtual memory systems...Terje Mathisen
|| |  ||  ||`- Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  |+* Re: Misc: Design tradeoffs in virtual memory systems...EricP
|| |  ||  ||`* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  || `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||  ||  `* Re: Misc: Design tradeoffs in virtual memory systems...robf...@gmail.com
|| |  ||  ||   `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  ||    +* Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  ||    |+* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  ||    ||`* Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  ||    || `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  ||    ||  `* Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  ||    ||   +* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||  ||    ||   |+- Re: Misc: Design tradeoffs in virtual memory systems...robf...@gmail.com
|| |  ||  ||    ||   |`- Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  ||    ||   +* Re: Misc: Design tradeoffs in virtual memory systems...Anton Ertl
|| |  ||  ||    ||   |+- Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| |  ||  ||    ||   |`- Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||  ||    ||   `* Re: Misc: Design tradeoffs in virtual memory systems...EricP
|| |  ||  ||    ||    `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  ||    ||     `- Re: Misc: Design tradeoffs in virtual memory systems...EricP
|| |  ||  ||    |+- Re: Misc: Design tradeoffs in virtual memory systems...EricP
|| |  ||  ||    |`- Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| |  ||  ||    +* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||  ||    |+- Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||  ||    |`- Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  ||    `- Re: Misc: Design tradeoffs in virtual memory systems...EricP
|| |  ||  |+- Re: Misc: Design tradeoffs in virtual memory systems...Ivan Godard
|| |  ||  |`- Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||  `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||   `* Re: Misc: Design tradeoffs in virtual memory systems...Anton Ertl
|| |  ||    +* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||    |`- Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||    `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||     +* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||     |+* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||     ||`- Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||     |`- Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||     `* Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||      `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||       `* Re: Misc: Design tradeoffs in virtual memory systems...Ivan Godard
|| |  ||        +- Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  ||        `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||         +* Re: Misc: Design tradeoffs in virtual memory systems...Stephen Fuld
|| |  ||         |+* Re: Misc: Design tradeoffs in virtual memory systems...robf...@gmail.com
|| |  ||         ||`- Re: Misc: Design tradeoffs in virtual memory systems...Stephen Fuld
|| |  ||         |`* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||         | `- Re: Misc: Design tradeoffs in virtual memory systems...Stephen Fuld
|| |  ||         `* Re: Misc: Design tradeoffs in virtual memory systems...Ivan Godard
|| |  ||          +- Re: Misc: Design tradeoffs in virtual memory systems...Thomas Koenig
|| |  ||          `* Re: Misc: Design tradeoffs in virtual memory systems...Paul A. Clayton
|| |  ||           `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||            `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  ||             `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  ||              +* Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| |  ||              |`- Re: Misc: Design tradeoffs in virtual memory systems...Thomas Koenig
|| |  ||              `- Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  |`* Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| |  | `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |  `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |   `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |    `* Re: Misc: Design tradeoffs in virtual memory systems...BGB-Alt
|| |  |     `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |      `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |       `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |        `* Re: Misc: Design tradeoffs in virtual memory systems...BGB-Alt
|| |  |         `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |          `* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  |           +- Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| |  |           +* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |           |`- Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |           +* Re: Misc: Design tradeoffs in virtual memory systems...John Levine
|| |  |           |`- Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
|| |  |           `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |            `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |             +- Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |             `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |              `* Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  |               `* Re: Misc: Design tradeoffs in virtual memory systems...Dan Cross
|| |  |                `- Re: Misc: Design tradeoffs in virtual memory systems...BGB
|| |  `- Re: Misc: Design tradeoffs in virtual memory systems...Scott Lurndal
|| `* Re: Misc: Design tradeoffs in virtual memory systems...Tim Rentsch
||  +- Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
||  `* Re: Misc: Design tradeoffs in virtual memory systems...John Levine
|`* Re: Misc: Design tradeoffs in virtual memory systems...Thomas Koenig
+* Re: Misc: Design tradeoffs in virtual memory systems...MitchAlsup
`* Re: Misc: Design tradeoffs in virtual memory systems...Anton Ertl

Pages:12345678
Re: Misc: Design tradeoffs in virtual memory systems...

<u67g72$35jc6$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32790&group=comp.arch#32790

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: sfuld@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Mon, 12 Jun 2023 09:13:20 -0700
Organization: A noiseless patient Spider
Lines: 41
Message-ID: <u67g72$35jc6$1@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u667t0$30ji3$1@dont-email.me>
<05c7426e-9646-481d-b71d-87b44eba5bc6n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 Jun 2023 16:13:22 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="30a296deabc9d4c3d69fd3fe72e9ba9f";
logging-data="3329414"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18OttPkwi3UXQBB+oQj4oQWutnGkTjpYy0="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:uoC7CNiPK4UGqkuYsFO/zL5WAnE=
Content-Language: en-US
In-Reply-To: <05c7426e-9646-481d-b71d-87b44eba5bc6n@googlegroups.com>
 by: Stephen Fuld - Mon, 12 Jun 2023 16:13 UTC

On 6/11/2023 11:23 PM, robf...@gmail.com wrote:
> On Monday, June 12, 2023 at 12:45:24 AM UTC-4, Stephen Fuld wrote:
>> On 6/11/2023 3:48 PM, MitchAlsup wrote:

snip

>>> One day I interviewed a guy for a position on the BASIC interpreter team
>>> we were building. His current profession was driving a Pepsi truck. He
>>> had never participated in any STEM activities in his life, and had dropped
>>> out of his residency in the 3rd year because he could no longer deal with
>>> watching people die.
>> If by residency, you mean medical residency, then he must have graduated
>> medical school, which means he had a fair number of science classes (the
>> S in STEM), and just having been admitted to medical school implies a
>> pretty smart guy who can learn new things well, so
>>> After a few weeks, he ended up being one of our best programmers we had
>>> EVER hired.
>> Not surprising.
>>
>>
>>> <
>>> So much for resumés..........
>>
>> It seems his resume actually told you a lot about his intelligence,
>> ability to learn, ability to reason well, willingness to work hard, etc.
>>
>>
>>
> I think one must be careful not to put too much weight on resumes or job
> adverts. It is very important to meet in person and get details. A good
> resume just gets one in the door. Many people can have written great
> sounding resumes.

Of course. Things like personality, the ability to get along with
others as part of a team, etc. are often not discernible from a resume.

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

Re: Misc: Design tradeoffs in virtual memory systems...

<u67jbs$2uqnb$1@newsreader4.netcologne.de>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32791&group=comp.arch#32791

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!newsreader4.netcologne.de!news.netcologne.de!.POSTED.2001-4dd7-2d6e-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoenig@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Mon, 12 Jun 2023 17:07:08 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <u67jbs$2uqnb$1@newsreader4.netcologne.de>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u677rp$34bhu$1@dont-email.me>
Injection-Date: Mon, 12 Jun 2023 17:07:08 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd7-2d6e-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd7:2d6e:0:7285:c2ff:fe6c:992d";
logging-data="3107563"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Mon, 12 Jun 2023 17:07 UTC

Ivan Godard <ivan@millcomputing.com> schrieb:

> Best programmer at PRC was an empty-nest woman hired as an assistant to
> the office manager. No STEM, but dual PhDs - one was French Medieval
> Literature and I forget the other, but similarly obscure.
>
> Job prereqs are just a device to let HR be lazy.

This is highly related to the kind of job, with programming actually
being an exception. But then, with programmers there is a _huge_
skill ratio between people, far bigger than in almost any other job.

I know some exceptional programmers who never studied computer science.
In most other fields, that is not so easy. For example, in a process
engineer whose job is to design thermal equipment (distillation columns,
heat exchangers, and so on). You need the basics in thermodynamics,
heat transfer, material science, mechanics etc to do that well.

Hm, come to think of it, maybe programming is different because
it is possible to get almost immediate feedback if something
is wrong - program coes not compile, you get wrong results etc,
so a learning curve can be quite steep for people who have the
talent.

If you design a heat exchanger, it gets delivered after a year
and, when the plant starts up six months later, it doesn't work,
it is too late for a "change that one line and recompile".

Re: Misc: Design tradeoffs in virtual memory systems...

<60b401c2-d869-4150-bba7-ffa9ec9654bcn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32797&group=comp.arch#32797

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:288:b0:3f6:b44b:d12c with SMTP id z8-20020a05622a028800b003f6b44bd12cmr3051052qtw.1.1686593084136;
Mon, 12 Jun 2023 11:04:44 -0700 (PDT)
X-Received: by 2002:a05:6830:63c4:b0:6b2:8edf:64ff with SMTP id
ci4-20020a05683063c400b006b28edf64ffmr3774383otb.2.1686593083833; Mon, 12 Jun
2023 11:04:43 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Mon, 12 Jun 2023 11:04:43 -0700 (PDT)
In-Reply-To: <u667t0$30ji3$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:7567:8988:6d81:ea5d;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:7567:8988:6d81:ea5d
References: <u4por8$3tugb$1@dont-email.me> <2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com> <u667t0$30ji3$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <60b401c2-d869-4150-bba7-ffa9ec9654bcn@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Mon, 12 Jun 2023 18:04:44 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Mon, 12 Jun 2023 18:04 UTC

On Sunday, June 11, 2023 at 11:45:24 PM UTC-5, Stephen Fuld wrote:
> On 6/11/2023 3:48 PM, MitchAlsup wrote:
> > On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
> >> On 6/5/2023 4:12 AM, Dan Cross wrote:
> >>> In article <u5ifdv$s3i$1...@dont-email.me>,
> >>> Paul A. Clayton <paaron...@gmail.com> wrote:
> >>>> On 5/29/23 3:27 PM, Dan Cross wrote:
> >>>>> In article <2023May2...@mips.complang.tuwien.ac.at>,
> >>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
> >>>>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
> >>>>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
> >>>>>>>> How many people have done much better with their hobby CPU ISA projects?...
> >>>>>>>
> >>>>>>> I haven't a clue. However, most undergrads who take an
> >>>>>>> architecture course do about the same.
> >>>>>>
> >>>>>> Implement a new architecture in an FPGA and get it to run Doom (which
> >>>>>> also means retargeting a compiler for his architecture)? I very much
> >>>>>> doubt it.
> >>>>
> >>>> I am impressed by his accomplishments. I wish the world would
> >>>> better exploit such human resources. He obviously has
> >>>> psychological issues (autism has been mentioned) which would make
> >>>> extracting the value more difficult, but he seems intelligent and
> >>>> *able to accomplish things*.
> >>>
> >>> It may be insensitive, but I don't really care what his problem
> >>> is, and I plonked him.
> >>>
> >>>>> Actually, I really don't think that is that far off. Maybe they
> >>>>> won't port a compiler or a reasonably large game, but so what?
> >>>>> By the time anyone is doing that, most of the really hard work
> >>>>> has been done.
> >>>>
> >>>> Porting a compiler like GCC or LLVM from a similar supported ISA
> >>>> may not be extraordinarily difficult (but I suspect such still
> >>>> involves a substantial investment in time). Undergraduates often
> >>>> have more resources and clearer guidelines than a relatively
> >>>> isolated self-taught person.
> >>>
> >>> Certainly. But just because someone is clever and does a thing
> >>> that does not a) imply that that person is qualified to work at
> >>> a higher level, or b) that they are an expert at the thing.
> >>>
> >>> One recognizes an undergraduate education as the beginning of
> >>> one's educational journey (be it followed by further study in an
> >>> academic context or a professional context), not the end.
> >> An undergraduate education was beyond the end for me. Despite having
> >> taught at the undergrad and graduate levels, my only diploma shows that
> >> I'm a proud graduate of Deer Isle High School. Graduated third in my
> >> class, mind you - of ten.
> >>
> >> Over the years I've hired a fair number of technical people. I've always
> >> had the policy to impose no recruiting requirement that I myself could
> >> not satisfy. However, there are some jobs I would actively seek out PhDs
> >> for, because sometimes you want someone with a demonstrated capacity to
> >> slog through interminable crap.
> > <
> > A long time ago, at a cash register plant in rural Ohio, we were writing cash
> > register applications in 8085 assembly language. The company policy was
> > basically, we would hire anyone who would show up and attempt to work
> > both on the technical side and on the manufacturing side. We also had a
> > policy that if you were not proficient at your job in 6 months we would add
> > training and apprenticeships and if you were still not descent at the job
> > you got laid off. Everyone knew this going in and out.
> > <
> > One day I interviewed a guy for a position on the BASIC interpreter team
> > we were building. His current profession was driving a Pepsi truck. He
> > had never participated in any STEM activities in his life, and had dropped
> > out of his residency in the 3rd year because he could no longer deal with
> > watching people die.
> If by residency, you mean medical residency, then he must have graduated
> medical school, which means he had a fair number of science classes (the
> S in STEM), and just having been admitted to medical school implies a
> pretty smart guy who can learn new things well, so
> > After a few weeks, he ended up being one of our best programmers we had
> > EVER hired.
> Not surprising.
>
>
> > <
> > So much for resumés..........
>
> It seems his resume actually told you a lot about his intelligence,
> ability to learn, ability to reason well, willingness to work hard, etc.
>
His resumé basically read "I drive a Pepsi truck".
>
>
> --
> - Stephen Fuld
> (e-mail address disguised to prevent spam)

Re: Misc: Design tradeoffs in virtual memory systems...

<u67ncl$36feo$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32799&group=comp.arch#32799

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: sfuld@alumni.cmu.edu.invalid (Stephen Fuld)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Mon, 12 Jun 2023 11:15:47 -0700
Organization: A noiseless patient Spider
Lines: 100
Message-ID: <u67ncl$36feo$1@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u667t0$30ji3$1@dont-email.me>
<60b401c2-d869-4150-bba7-ffa9ec9654bcn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 12 Jun 2023 18:15:50 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="30a296deabc9d4c3d69fd3fe72e9ba9f";
logging-data="3358168"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19KT18VQTtyfYdQtB9bB33KAxjXYfQFqXA="
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.12.0
Cancel-Lock: sha1:LeKFBlLjGppPGBPaYXWGaQYaEbA=
Content-Language: en-US
In-Reply-To: <60b401c2-d869-4150-bba7-ffa9ec9654bcn@googlegroups.com>
 by: Stephen Fuld - Mon, 12 Jun 2023 18:15 UTC

On 6/12/2023 11:04 AM, MitchAlsup wrote:
> On Sunday, June 11, 2023 at 11:45:24 PM UTC-5, Stephen Fuld wrote:
>> On 6/11/2023 3:48 PM, MitchAlsup wrote:
>>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
>>>>> In article <u5ifdv$s3i$1...@dont-email.me>,
>>>>> Paul A. Clayton <paaron...@gmail.com> wrote:
>>>>>> On 5/29/23 3:27 PM, Dan Cross wrote:
>>>>>>> In article <2023May2...@mips.complang.tuwien.ac.at>,
>>>>>>> Anton Ertl <an...@mips.complang.tuwien.ac.at> wrote:
>>>>>>>> cr...@spitfire.i.gajendra.net (Dan Cross) writes:
>>>>>>>>> In article <u4rm3o$52b5$1...@dont-email.me>, BGB <cr8...@gmail.com> wrote:
>>>>>>>>>> How many people have done much better with their hobby CPU ISA projects?...
>>>>>>>>>
>>>>>>>>> I haven't a clue. However, most undergrads who take an
>>>>>>>>> architecture course do about the same.
>>>>>>>>
>>>>>>>> Implement a new architecture in an FPGA and get it to run Doom (which
>>>>>>>> also means retargeting a compiler for his architecture)? I very much
>>>>>>>> doubt it.
>>>>>>
>>>>>> I am impressed by his accomplishments. I wish the world would
>>>>>> better exploit such human resources. He obviously has
>>>>>> psychological issues (autism has been mentioned) which would make
>>>>>> extracting the value more difficult, but he seems intelligent and
>>>>>> *able to accomplish things*.
>>>>>
>>>>> It may be insensitive, but I don't really care what his problem
>>>>> is, and I plonked him.
>>>>>
>>>>>>> Actually, I really don't think that is that far off. Maybe they
>>>>>>> won't port a compiler or a reasonably large game, but so what?
>>>>>>> By the time anyone is doing that, most of the really hard work
>>>>>>> has been done.
>>>>>>
>>>>>> Porting a compiler like GCC or LLVM from a similar supported ISA
>>>>>> may not be extraordinarily difficult (but I suspect such still
>>>>>> involves a substantial investment in time). Undergraduates often
>>>>>> have more resources and clearer guidelines than a relatively
>>>>>> isolated self-taught person.
>>>>>
>>>>> Certainly. But just because someone is clever and does a thing
>>>>> that does not a) imply that that person is qualified to work at
>>>>> a higher level, or b) that they are an expert at the thing.
>>>>>
>>>>> One recognizes an undergraduate education as the beginning of
>>>>> one's educational journey (be it followed by further study in an
>>>>> academic context or a professional context), not the end.
>>>> An undergraduate education was beyond the end for me. Despite having
>>>> taught at the undergrad and graduate levels, my only diploma shows that
>>>> I'm a proud graduate of Deer Isle High School. Graduated third in my
>>>> class, mind you - of ten.
>>>>
>>>> Over the years I've hired a fair number of technical people. I've always
>>>> had the policy to impose no recruiting requirement that I myself could
>>>> not satisfy. However, there are some jobs I would actively seek out PhDs
>>>> for, because sometimes you want someone with a demonstrated capacity to
>>>> slog through interminable crap.
>>> <
>>> A long time ago, at a cash register plant in rural Ohio, we were writing cash
>>> register applications in 8085 assembly language. The company policy was
>>> basically, we would hire anyone who would show up and attempt to work
>>> both on the technical side and on the manufacturing side. We also had a
>>> policy that if you were not proficient at your job in 6 months we would add
>>> training and apprenticeships and if you were still not descent at the job
>>> you got laid off. Everyone knew this going in and out.
>>> <
>>> One day I interviewed a guy for a position on the BASIC interpreter team
>>> we were building. His current profession was driving a Pepsi truck. He
>>> had never participated in any STEM activities in his life, and had dropped
>>> out of his residency in the 3rd year because he could no longer deal with
>>> watching people die.
>> If by residency, you mean medical residency, then he must have graduated
>> medical school, which means he had a fair number of science classes (the
>> S in STEM), and just having been admitted to medical school implies a
>> pretty smart guy who can learn new things well, so
>>> After a few weeks, he ended up being one of our best programmers we had
>>> EVER hired.
>> Not surprising.
>>
>>
>>> <
>>> So much for resumés..........
>>
>> It seems his resume actually told you a lot about his intelligence,
>> ability to learn, ability to reason well, willingness to work hard, etc.
>>
> His resumé basically read "I drive a Pepsi truck".

OK, of course, I believe you, but it does seem odd. Most people would
include at least their college education, and in his case, presumably
medical school. If he was so underplaying his capabilities, you were
indeed fortunate to find him.

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

Re: Misc: Design tradeoffs in virtual memory systems...

<u6smn7$2gaa7$5@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32882&group=comp.arch#32882

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: paaronclayton@gmail.com (Paul A. Clayton)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Tue, 20 Jun 2023 13:13:11 -0400
Organization: A noiseless patient Spider
Lines: 119
Message-ID: <u6smn7$2gaa7$5@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<Ia3cM.3440031$iU59.2338510@fx14.iad>
<u4vj9n$25m1c$1@newsreader4.netcologne.de>
<hHLcM.4041635$GNG9.1173433@fx18.iad> <u50hb0$ijs$1@gal.iecc.com>
<2023May29.142305@mips.complang.tuwien.ac.at>
<jV1dM.3731948$vBI8.2298283@fx15.iad> <u53eoq$1mvgs$1@dont-email.me>
<be4aa5b0-0d06-4198-a6fc-347b1eee44e7n@googlegroups.com>
<u62kjd$2dc9h$4@dont-email.me>
<297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 Jun 2023 17:13:11 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f3d0bcd62b374bce57dd1eafa9d08e5f";
logging-data="2632007"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+sToUeUWg+rv3uZfAfFUTMeUPyfCygVWM="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.0
Cancel-Lock: sha1:x7C0wcWncRXC7/oD8mpfk7WSLrw=
In-Reply-To: <297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com>
X-Mozilla-News-Host: news://news.eternal-september.org
 by: Paul A. Clayton - Tue, 20 Jun 2023 17:13 UTC

On 6/10/23 9:09 PM, MitchAlsup wrote:
> On Saturday, June 10, 2023 at 2:57:37 PM UTC-5, Paul A. Clayton wrote:
>> On 5/29/23 9:07 PM, MitchAlsup wrote:
>>> On Monday, May 29, 2023 at 7:07:58 PM UTC-5, Paul A. Clayton wrote:
[snip]
>> I am of the opinion that most documentation should not use a
>> single-view print-oriented format (like PDF). (I do admit that
>> spatial recognition is important for re-referencing content,
>> especially when one cannot think of the appropriate search terms
>> but has a memory of "landmarks" and general location. I suspect
>> there are ways to provide similar memory keys without requiring
>> consistent pagination.)
> <
> Is rampant cross reference links not sufficient here ?

Just as function inlining is sometimes appropriate even when
function call costs have been greatly reduced, so following
references is not always the ideal organization.

Even in print media, there is a distinction between general cross
reference, index/glossary reference, endnote, footnote, side note,
and abbreviation that is expected to be known (which can include
marks indicating things like "translation uncertain", "weak
manuscript evidence", etc., such would be expanded in a
"Conventions" section).

[snip]
>> Maybe I am strange and/or mistrained in losing focus from link
>> following. (I can see how making content visible or hidden
>> dynamically could further hurt the "spatial memory", but for
>> shortish content such might be better than a link.)
> <
> You need a reader where you can follow a link and return whence
> you followed.

Visually returning is only part of the problem. Mental flow is
more disrupted (at least for me) by an "external" reference. (This
might be similar to the difference between a properly
parenthetical statement — not my use of parentheses! — and
checking another book already opened to the appropriate page.)

> <
> But (the BIG but) all sufficiently well described architectures end
> up in the position that the reader has to read all the documents in
> order to be in a position to read the documents with understanding.

That seems pretty much true of all knowledge. To grok a system one
has to consume the whole thing. Sufficient understanding to use as
a reference for certain types of questions is less demanding
(though more dangerous, one can ask the wrong questions or
misapply the answers by attributing incorrect context)

> At a place of employment, one needs a ceiling height by 40 foot
> long "white board" to draw a schematic for the µArchitecture in
> sufficient detail to find and reason about (then correct) the
> "schematic". Scrolling around on a screen with a schematic that
> is 100×screen sizes big is not workable....

I wonder why this would be physically/psychologically necessary. A
human's field of view is smaller (especially if one wears glasses)
and the primary focus even more limited. In theory visual virtual
reality should be as good.

I am guessing that there is some physical movement spatial clues
helping the mind discern context and 'mark' matters of focus.
(Weird thought: a rotating chair might provide a similar interface
to turning one's head to look aside [from a fixed position]. A
"mouse chair" seems like a very strange concept, though foot
pedals are a well known interface.)

A huge whiteboard would seem to have the disadvantage(?) of slow
focus change, especially for very myopic people.

[snip]
> There are 61 spellings the assembly language programmer has
> to memorize to capture the whole instruction set in his head.
> {Not to mention there is no SUB instruction, or NEG, or COMP
> instruction, no FMULSUB, and a host of other "spellings".} in
> My 66000 the OpCode describes the calculation, those other 32
> forms describe the routing of operand to the calculation.

For an assembly-level view, other ISAs could provide a similar
organization. Having a separate SUB opcode does not seem
significant to the assembly programmer. Encoding length and
especially instruction count can be important for assembly-level
programming, but unless one is using code as data, the bit pattern
and layout is not important. Even instruction-level atomicity is
probably not important most of the time (though having such simply
implied would avoid confusion and tracking overhead if/when
atomicity is significant).

MIPS, e.g., could easily have used an assembly language that did
not distinguish ADD from ADDI in the opcode name but in the
argument list.

(I do not want to dismiss the advantage of a shallower abstraction
between assembly and machine code. I think My 66000 is elegant.
However, the advantage seems modest.)

[snip]
> I (do) understand what you are getting at, but (as yet) we don't
> really have a way of having 89 views into a document on 89 windows
> so we can see all the nuances that one complicated instruction
> brings to the party (for better or worse). {{See 10 minutes before
> the end of Lawnmower Man}}

I guess I should look up that reference.

I suspect there is a physical interface that provides better
overall usability than print and current display-based interfaces.

(I very much like having a much larger document collection than I
can afford to acquire or store in print. Yet I confess to liking
the feel of a book; a tablet can be somewhat cosy but a little
more awkward than a mass market paperback to hold — especially as
dropping can be much more expensive — and a backlit display may be
harder on my eyes [though being able to scale fonts can be an
advantage even though the reader software does not seem to handle
this well, providing only a few font size choices].)

Re: Misc: Design tradeoffs in virtual memory systems...

<u6smnf$2gaa7$7@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32884&group=comp.arch#32884

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: paaronclayton@gmail.com (Paul A. Clayton)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Tue, 20 Jun 2023 13:13:19 -0400
Organization: A noiseless patient Spider
Lines: 64
Message-ID: <u6smnf$2gaa7$7@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u677rp$34bhu$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 Jun 2023 17:13:19 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="f3d0bcd62b374bce57dd1eafa9d08e5f";
logging-data="2632007"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/7vR6TwQHIxHyPEgcjlz8wVFSyMUNnvfI="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.0
Cancel-Lock: sha1:IO/8PBXAM0nkSJIrH9bfpt1VyUI=
X-Mozilla-News-Host: news://news.eternal-september.org
In-Reply-To: <u677rp$34bhu$1@dont-email.me>
 by: Paul A. Clayton - Tue, 20 Jun 2023 17:13 UTC

On 6/12/23 9:50 AM, Ivan Godard wrote:
> On 6/11/2023 3:48 PM, MitchAlsup wrote:
>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
[snip]
>>>> Certainly. But just because someone is clever and does a thing
>>>> that does not a) imply that that person is qualified to work at
>>>> a higher level, or b) that they are an expert at the thing.

I agree and this is one reason I doubt I could provide sufficient
value in a tech job. My anxiety, depression, and "not-good-enough-
ism" (a.k.a., perfectionism) hinder getting anything done that has
the significant potential for significant failure. This hinders
even learning about new difficult topics (where failure is more
likely), especially when not "just for fun" (failure is not as
important with 'games' though it can still be painful).

Even if some employer hired me (ignoring my non-work history and
psychological issues), I doubt I could be well integrated and
productive (doing a good job is important to me). Most managers
seem to be mediocre to poor at managing ordinary people and even
less skilled at managing "special needs" people. (E.g., most
managers do not seem to realize that "X is a good result" could
stir more pride and less anxiety than "you did X well". Three of
five of the comments on a recently received appreciation card
included "keep up the good work", presumably not realizing that
such sets up a high baseline for mere acceptance and to be
appreciated I have to do even more. Ordinary people would probably
receive "keep up the good work" more as "you got this!", i.e., an
affirmation.)

(I have encountered good managers — happily not any truly bad
managers, merely some that were not very competent. I also know
that managing people is *difficult* and far outside my
competencies.)

[snip]
>> After a few weeks, he ended up being one of our best programmers
>> we had EVER hired.
>>
>> So much for resumés..........

Presumably the medical background was not included in the resumé
because he did not want to return to that type of work.

[snip]

> Job prereqs are just a device to let HR be lazy.

Any policy (vs. case by case handling) is applied primarily to
reduce effort (and potential for error). Formal policies also
provide "cover your ass". One will not be blamed from failures
when following an approved policy, even if the policy does not
promote the intended outcomes as well as deviating a little.
(While forgiveness is often easier to get than permission,
forgiveness is often dependent on outcome and earlier "forgiven"
transgressions can be brought back to justify more extreme
punishment for a later falling short.)

Cookie cutter employees make management easier, especially in
large organizations. Such also encourages mediocrity, both from
hiring and internal incentives. Hiring and managing cats is more
difficult than buying and using cogs — and the latter is not
trivial.

Re: Misc: Design tradeoffs in virtual memory systems...

<NOlkM.1158$o5e9.8@fx37.iad>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32886&group=comp.arch#32886

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx37.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: scott@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Newsgroups: comp.arch
References: <u4por8$3tugb$1@dont-email.me> <Ia3cM.3440031$iU59.2338510@fx14.iad> <u4vj9n$25m1c$1@newsreader4.netcologne.de> <hHLcM.4041635$GNG9.1173433@fx18.iad> <u50hb0$ijs$1@gal.iecc.com> <2023May29.142305@mips.complang.tuwien.ac.at> <jV1dM.3731948$vBI8.2298283@fx15.iad> <u53eoq$1mvgs$1@dont-email.me> <be4aa5b0-0d06-4198-a6fc-347b1eee44e7n@googlegroups.com> <u62kjd$2dc9h$4@dont-email.me> <297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com> <u6smn7$2gaa7$5@dont-email.me>
Lines: 23
Message-ID: <NOlkM.1158$o5e9.8@fx37.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Tue, 20 Jun 2023 18:00:13 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Tue, 20 Jun 2023 18:00:13 GMT
X-Received-Bytes: 2059
 by: Scott Lurndal - Tue, 20 Jun 2023 18:00 UTC

"Paul A. Clayton" <paaronclayton@gmail.com> writes:
>On 6/10/23 9:09 PM, MitchAlsup wrote:

>>> Maybe I am strange and/or mistrained in losing focus from link
>>> following. (I can see how making content visible or hidden
>>> dynamically could further hurt the "spatial memory", but for
>>> shortish content such might be better than a link.)
>> <
>> You need a reader where you can follow a link and return whence
>> you followed.
>
>Visually returning is only part of the problem. Mental flow is
>more disrupted (at least for me) by an "external" reference. (This
>might be similar to the difference between a properly
>parenthetical statement — not my use of parentheses! — and
>checking another book already opened to the appropriate page.)

For PDF documents, I've found xpdf to be far superior to Acrobat
or evince. Both in performance and UI. xpdf supports both
link following and has an inifinite back button. The UI is
page-based, instead of scroll based.

I use xpdf for all the ARM reference manuals.

Re: Misc: Design tradeoffs in virtual memory systems...

<0d6b386d-bdda-4d48-a4ff-1946cd4c9686n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32890&group=comp.arch#32890

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:25b:b0:763:ace0:7e65 with SMTP id q27-20020a05620a025b00b00763ace07e65mr543185qkn.14.1687288179250;
Tue, 20 Jun 2023 12:09:39 -0700 (PDT)
X-Received: by 2002:a05:6830:20c9:b0:6b0:c72c:c9dc with SMTP id
z9-20020a05683020c900b006b0c72cc9dcmr2046800otq.7.1687288178995; Tue, 20 Jun
2023 12:09:38 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 20 Jun 2023 12:09:38 -0700 (PDT)
In-Reply-To: <u6smn7$2gaa7$5@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:315b:1da6:985c:6101;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:315b:1da6:985c:6101
References: <u4por8$3tugb$1@dont-email.me> <Ia3cM.3440031$iU59.2338510@fx14.iad>
<u4vj9n$25m1c$1@newsreader4.netcologne.de> <hHLcM.4041635$GNG9.1173433@fx18.iad>
<u50hb0$ijs$1@gal.iecc.com> <2023May29.142305@mips.complang.tuwien.ac.at>
<jV1dM.3731948$vBI8.2298283@fx15.iad> <u53eoq$1mvgs$1@dont-email.me>
<be4aa5b0-0d06-4198-a6fc-347b1eee44e7n@googlegroups.com> <u62kjd$2dc9h$4@dont-email.me>
<297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com> <u6smn7$2gaa7$5@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <0d6b386d-bdda-4d48-a4ff-1946cd4c9686n@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Tue, 20 Jun 2023 19:09:39 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 8441
 by: MitchAlsup - Tue, 20 Jun 2023 19:09 UTC

On Tuesday, June 20, 2023 at 12:13:15 PM UTC-5, Paul A. Clayton wrote:
> On 6/10/23 9:09 PM, MitchAlsup wrote:
> > On Saturday, June 10, 2023 at 2:57:37 PM UTC-5, Paul A. Clayton wrote:
> >> On 5/29/23 9:07 PM, MitchAlsup wrote:
> >>> On Monday, May 29, 2023 at 7:07:58 PM UTC-5, Paul A. Clayton wrote:
> [snip]
> >> I am of the opinion that most documentation should not use a
> >> single-view print-oriented format (like PDF). (I do admit that
> >> spatial recognition is important for re-referencing content,
> >> especially when one cannot think of the appropriate search terms
> >> but has a memory of "landmarks" and general location. I suspect
> >> there are ways to provide similar memory keys without requiring
> >> consistent pagination.)
> > <
> > Is rampant cross reference links not sufficient here ?
> Just as function inlining is sometimes appropriate even when
> function call costs have been greatly reduced, so following
> references is not always the ideal organization.
>
> Even in print media, there is a distinction between general cross
> reference, index/glossary reference, endnote, footnote, side note,
> and abbreviation that is expected to be known (which can include
> marks indicating things like "translation uncertain", "weak
> manuscript evidence", etc., such would be expanded in a
> "Conventions" section).
>
> [snip]
> >> Maybe I am strange and/or mistrained in losing focus from link
> >> following. (I can see how making content visible or hidden
> >> dynamically could further hurt the "spatial memory", but for
> >> shortish content such might be better than a link.)
> > <
> > You need a reader where you can follow a link and return whence
> > you followed.
> Visually returning is only part of the problem. Mental flow is
> more disrupted (at least for me) by an "external" reference. (This
> might be similar to the difference between a properly
> parenthetical statement — not my use of parentheses! — and
> checking another book already opened to the appropriate page.)
> > <
> > But (the BIG but) all sufficiently well described architectures end
> > up in the position that the reader has to read all the documents in
> > order to be in a position to read the documents with understanding.
> That seems pretty much true of all knowledge. To grok a system one
> has to consume the whole thing. Sufficient understanding to use as
> a reference for certain types of questions is less demanding
> (though more dangerous, one can ask the wrong questions or
> misapply the answers by attributing incorrect context)
> > At a place of employment, one needs a ceiling height by 40 foot
> > long "white board" to draw a schematic for the µArchitecture in
> > sufficient detail to find and reason about (then correct) the
> > "schematic". Scrolling around on a screen with a schematic that
> > is 100×screen sizes big is not workable....
<
> I wonder why this would be physically/psychologically necessary. A
> human's field of view is smaller (especially if one wears glasses)
> and the primary focus even more limited. In theory visual virtual
> reality should be as good.
<
You might have k engineers working simultaneously on different sections
of the schematic at the same time. 1 < k < 32
>
> I am guessing that there is some physical movement spatial clues
> helping the mind discern context and 'mark' matters of focus.
> (Weird thought: a rotating chair might provide a similar interface
> to turning one's head to look aside [from a fixed position]. A
> "mouse chair" seems like a very strange concept, though foot
> pedals are a well known interface.)
>
> A huge whiteboard would seem to have the disadvantage(?) of slow
> focus change, especially for very myopic people.
<
But the advantage that k people can be changing it simultaneously.
>
> [snip]
> > There are 61 spellings the assembly language programmer has
> > to memorize to capture the whole instruction set in his head.
> > {Not to mention there is no SUB instruction, or NEG, or COMP
> > instruction, no FMULSUB, and a host of other "spellings".} in
> > My 66000 the OpCode describes the calculation, those other 32
> > forms describe the routing of operand to the calculation.
<
> For an assembly-level view, other ISAs could provide a similar
> organization. Having a separate SUB opcode does not seem
> significant to the assembly programmer. Encoding length and
> especially instruction count can be important for assembly-level
> programming, but unless one is using code as data, the bit pattern
> and layout is not important. Even instruction-level atomicity is
> probably not important most of the time (though having such simply
> implied would avoid confusion and tracking overhead if/when
> atomicity is significant).
>
> MIPS, e.g., could easily have used an assembly language that did
> not distinguish ADD from ADDI in the opcode name but in the
> argument list.
>
> (I do not want to dismiss the advantage of a shallower abstraction
> between assembly and machine code. I think My 66000 is elegant.
> However, the advantage seems modest.)
<
Agreed that the assembly language is but a modest simplification.
<
The useful gain is that I require only 75% the number of instructions
as MIPS or RISC-V; and that this gain comes from only 5 features.
>
> [snip]
> > I (do) understand what you are getting at, but (as yet) we don't
> > really have a way of having 89 views into a document on 89 windows
> > so we can see all the nuances that one complicated instruction
> > brings to the party (for better or worse). {{See 10 minutes before
> > the end of Lawnmower Man}}
> I guess I should look up that reference.
>
> I suspect there is a physical interface that provides better
> overall usability than print and current display-based interfaces.
>
> (I very much like having a much larger document collection than I
> can afford to acquire or store in print. Yet I confess to liking
> the feel of a book; a tablet can be somewhat cosy but a little
> more awkward than a mass market paperback to hold — especially as
> dropping can be much more expensive — and a backlit display may be
> harder on my eyes [though being able to scale fonts can be an
> advantage even though the reader software does not seem to handle
> this well, providing only a few font size choices].)

Re: Misc: Design tradeoffs in virtual memory systems...

<u6t9be$2idkj$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32895&group=comp.arch#32895

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: paaronclayton@gmail.com (Paul A. Clayton)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Tue, 20 Jun 2023 18:31:08 -0400
Organization: A noiseless patient Spider
Lines: 23
Message-ID: <u6t9be$2idkj$1@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<Ia3cM.3440031$iU59.2338510@fx14.iad>
<u4vj9n$25m1c$1@newsreader4.netcologne.de>
<hHLcM.4041635$GNG9.1173433@fx18.iad> <u50hb0$ijs$1@gal.iecc.com>
<2023May29.142305@mips.complang.tuwien.ac.at>
<jV1dM.3731948$vBI8.2298283@fx15.iad> <u53eoq$1mvgs$1@dont-email.me>
<be4aa5b0-0d06-4198-a6fc-347b1eee44e7n@googlegroups.com>
<u62kjd$2dc9h$4@dont-email.me>
<297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com>
<u6smn7$2gaa7$5@dont-email.me>
<0d6b386d-bdda-4d48-a4ff-1946cd4c9686n@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Tue, 20 Jun 2023 22:31:10 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="9caf576210a0e7c2cc13be9efda63e6b";
logging-data="2700947"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JhvU0mViFbTb0E2VKaQw6MNRl/GsD4C8="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.0
Cancel-Lock: sha1:nwlnLyW+QdEdBEhq0YtghWayoyk=
In-Reply-To: <0d6b386d-bdda-4d48-a4ff-1946cd4c9686n@googlegroups.com>
 by: Paul A. Clayton - Tue, 20 Jun 2023 22:31 UTC

On 6/20/23 3:09 PM, MitchAlsup wrote:
> On Tuesday, June 20, 2023 at 12:13:15 PM UTC-5, Paul A. Clayton wrote:
[snip]
>> A huge whiteboard would seem to have the disadvantage(?) of slow
>> focus change, especially for very myopic people.
> <
> But the advantage that k people can be changing it simultaneously.

Semi-independent electronic displays could have their driving
hardware/computer networked for a consistent presentation with
"remote" modifications. One could even choose to view a local
snapshot (perhaps intermittently glancing at/overlaying changes).
Such "fixable" distinctions do not seem to entirely expose what
makes these methods of collaboration feel different and work
differently (often less well).

(I do realize that there is a difference between local
collaboration and remote collaboration. I do not understand the
psychology of why — some seems to be picking up subtle clues about
others' focus. I also do not know how much of this is learned —
likely to a large degree in childhood, I suspect — nor how
difficult retraining would be assuming that remote collaboration
could include other clues/cues and etiquette.)

Re: Misc: Design tradeoffs in virtual memory systems...

<72795088-b731-4fec-8a39-e2657c4f94f2n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32897&group=comp.arch#32897

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:620a:1a08:b0:762:5602:29ae with SMTP id bk8-20020a05620a1a0800b00762560229aemr2103309qkb.6.1687301555664;
Tue, 20 Jun 2023 15:52:35 -0700 (PDT)
X-Received: by 2002:a05:6870:3a0b:b0:1a9:c186:398c with SMTP id
du11-20020a0568703a0b00b001a9c186398cmr1056389oab.3.1687301555427; Tue, 20
Jun 2023 15:52:35 -0700 (PDT)
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Tue, 20 Jun 2023 15:52:35 -0700 (PDT)
In-Reply-To: <u6t9be$2idkj$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:315b:1da6:985c:6101;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:315b:1da6:985c:6101
References: <u4por8$3tugb$1@dont-email.me> <Ia3cM.3440031$iU59.2338510@fx14.iad>
<u4vj9n$25m1c$1@newsreader4.netcologne.de> <hHLcM.4041635$GNG9.1173433@fx18.iad>
<u50hb0$ijs$1@gal.iecc.com> <2023May29.142305@mips.complang.tuwien.ac.at>
<jV1dM.3731948$vBI8.2298283@fx15.iad> <u53eoq$1mvgs$1@dont-email.me>
<be4aa5b0-0d06-4198-a6fc-347b1eee44e7n@googlegroups.com> <u62kjd$2dc9h$4@dont-email.me>
<297ecb4c-8830-4b86-a8c6-a4706ffe7f79n@googlegroups.com> <u6smn7$2gaa7$5@dont-email.me>
<0d6b386d-bdda-4d48-a4ff-1946cd4c9686n@googlegroups.com> <u6t9be$2idkj$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <72795088-b731-4fec-8a39-e2657c4f94f2n@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Tue, 20 Jun 2023 22:52:35 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Tue, 20 Jun 2023 22:52 UTC

On Tuesday, June 20, 2023 at 5:31:13 PM UTC-5, Paul A. Clayton wrote:
> On 6/20/23 3:09 PM, MitchAlsup wrote:
> > On Tuesday, June 20, 2023 at 12:13:15 PM UTC-5, Paul A. Clayton wrote:
> [snip]
> >> A huge whiteboard would seem to have the disadvantage(?) of slow
> >> focus change, especially for very myopic people.
> > <
> > But the advantage that k people can be changing it simultaneously.
<
> Semi-independent electronic displays could have their driving
> hardware/computer networked for a consistent presentation with
> "remote" modifications. One could even choose to view a local
> snapshot (perhaps intermittently glancing at/overlaying changes).
> Such "fixable" distinctions do not seem to entirely expose what
> makes these methods of collaboration feel different and work
> differently (often less well).
<
People have the innate ability, when multiple show up at the same place,
to change from updating the drawing to discussing what should be drawn.
<
>
> (I do realize that there is a difference between local
> collaboration and remote collaboration. I do not understand the
> psychology of why — some seems to be picking up subtle clues about
> others' focus. I also do not know how much of this is learned —
> likely to a large degree in childhood, I suspect — nor how
> difficult retraining would be assuming that remote collaboration
> could include other clues/cues and etiquette.)

Re: Misc: Design tradeoffs in virtual memory systems...

<u70li1$377tm$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32914&group=comp.arch#32914

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: cr88192@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Thu, 22 Jun 2023 00:17:51 -0500
Organization: A noiseless patient Spider
Lines: 202
Message-ID: <u70li1$377tm$1@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u677rp$34bhu$1@dont-email.me> <u6smnf$2gaa7$7@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 Jun 2023 05:17:53 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="024e096215e51e110a7f4b97a422cf62";
logging-data="3383222"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19afiqUkWDxNbJHKzSSByyz"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.2
Cancel-Lock: sha1:7YFMfs8RDSzC14T8ujSCiIoxu5Y=
In-Reply-To: <u6smnf$2gaa7$7@dont-email.me>
Content-Language: en-US
 by: BGB - Thu, 22 Jun 2023 05:17 UTC

On 6/20/2023 12:13 PM, Paul A. Clayton wrote:
> On 6/12/23 9:50 AM, Ivan Godard wrote:
>> On 6/11/2023 3:48 PM, MitchAlsup wrote:
>>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
> [snip]
>>>>> Certainly. But just because someone is clever and does a thing
>>>>> that does not a) imply that that person is qualified to work at
>>>>> a higher level, or b) that they are an expert at the thing.
>
> I agree and this is one reason I doubt I could provide sufficient
> value in a tech job. My anxiety, depression, and "not-good-enough-
> ism" (a.k.a., perfectionism) hinder getting anything done that has
> the significant potential for significant failure. This hinders
> even learning about new difficult topics (where failure is more
> likely), especially when not "just for fun" (failure is not as
> important with 'games' though it can still be painful).
>

Yeah.

I don't get where the whole thing about "claiming to be an expert" was
coming from; as far as I know, I was doing nothing of the sort.

The whole thing was kind of weird, not sure what was going on exactly,
but will admit to have been getting rather annoyed about it...

I was not claiming that I have a particularly solid understanding of
hypervisors or virtualization, as I was under the (possibly mistaken)
assumption that they were a sort of hardware-assisted form of emulation:
Which ironically, was N/A under Soft-TLB both because the TLB is
flexible enough that the relevant hardware trickery is unnecessary, and
also low-level enough that the OS level support for virtual memory is
much closer to what an emulator would do already (since in this case,
the underlying hardware leaves too much of its "guts" hanging out in the
open).

But, one could take this as either:
Hypervisors, in the traditional sense, are N/A;
Or, alternatively, that the hardware "can't" do a hypervisor due
providing a level of abstraction that is too low.

Still didn't see too much that was obviously outside the scope of what
could be handled with the existing mechanisms and some additional lookup
tables.

Though, at least for emulating x86, the more obvious problem cases are
more things like condition codes and things like Real-Mode / 16-bit
PMode / Big-Real Mode. These would likely require either using more
complex address calculations internally, or needing to add more complex
logic to the TLB.

The likely more practical option would be to do more complex addressing:
ADD BaseAddr, SegBase, TmpBase
LEA.x (TmpBase, Index), TmpBase
MOV.x (TmpBase, Disp), Dest

Though, this would also come with needing to emulate all the PC style
hardware as well, ...

I will still assert, that I was not talking, in any case about a server
context (and have no idea what exactly a server would using a hypervisor
for in the first place...).

My understanding was more in the context of things like VMware or
VirtualBox, which were (IME) typically used for things like running
older versions of Windows or similar (say, one runs 32-bit WinXP so that
they can run older games or similar that no longer run on modern 64-bit
Windows).

But, say, neither of these programs work anymore, so I am mostly limited
to QEMU and DOSBox (say, a lot of this old software also being old
enough to run on DOS and/or Win3.11 ...).

In this sense, the difference between "Virtualization" and "Emulation"
being a bit more abstract, since from the the user perspective both are
basically doing the same thing (and the performance differences are less
of an issue, since a modern PC is way faster than what most Win3.x or
Win9x software was designed for).

I can write from experience though, of having used (and written) various
emulators (and having an idea how it would work on BJX2; just leaving it
open how to best do it in a way where "the performance doesn't suck").

> Even if some employer hired me (ignoring my non-work history and
> psychological issues), I doubt I could be well integrated and
> productive (doing a good job is important to me). Most managers
> seem to be mediocre to poor at managing ordinary people and even
> less skilled at managing "special needs" people. (E.g., most
> managers do not seem to realize that "X is a good result" could
> stir more pride and less anxiety than "you did X well". Three of
> five of the comments on a recently received appreciation card
> included "keep up the good work", presumably not realizing that
> such sets up a high baseline for mere acceptance and to be
> appreciated I have to do even more. Ordinary people would probably
> receive "keep up the good work" more as "you got this!", i.e., an
> affirmation.)
>

I probably fall in the same category here...

Can't get a job, pretty much anywhere, doing pretty much anything.
Setting up a machine shop and making parts is at least slightly more
straightforward.

Trying to hold 0.005" on CNC conversion kits on manual machines is a bit
more of a problem though. More a case of, "Yeah, you will have to be
happy if it is +/- 0.015 ..."

Like, say, there is a bit of a difference between a "Grizzly Bench-Top
Mill" (with some steppers bolted on) and a "Haas Machining Center"...

No idea how to make money from either my software or Verilog efforts
though...

> (I have encountered good managers — happily not any truly bad
> managers, merely some that were not very competent. I also know
> that managing people is *difficult* and far outside my
> competencies.)
>

My social skills are almost non-existent...

But, as noted, I am autistic (Asperger's), seem to have alexithymia, and
(probably) am also asexual (not confirmed for certain, but evidence
seems to point this way).

Some other things I had wondered about, but they seem more to be
side-products of the above, rather than conditions in their own right
(for example, Alexithymia can also lead to tending towards a
Machiavellian outlook, but seemingly differs from the "actual" form of
Machiavellianism in that it doesn't necessarily lead to a desire to act
in a selfish or exploitative way towards others; more just sort of
"well, that is how the world works; kinda sucks, just gotta live with
it", ...).

I have realized don't that I don't particularly understand either
physical or romantic attraction. What I once thought they were, was in
effect a different emotion; seemingly an adaptation of either
"autophobia" or "social anxiety" into a form superficially resembling
some traditional aspects of romantic attraction.

Well, and culturally, it is assumed that one is either physically or
romantically attracted to someone; not necessarily that a person is
afraid of the future and essentially wants to use the other person as a
sort of "security blanket".

But, OTOH, since the way it is portrayed in media often isn't too far
different, had sort of assumed they are one and the same, and that
everyone else was effectively experiencing something similar.

But, then one partly gets over the "fear" aspects, and starts to realize
that they don't actually understand. And, the whole thing starts to seem
a little abstract (and all I really know is the superficial behaviors
and social conventions, but not really the meanings of feelings behind
them).

....

> [snip]
>>> After a few weeks, he ended up being one of our best programmers we
>>> had EVER hired.
>>>
>>> So much for resumés..........
>
> Presumably the medical background was not included in the resumé
> because he did not want to return to that type of work.
>
> [snip]
>
>> Job prereqs are just a device to let HR be lazy.
>
> Any policy (vs. case by case handling) is applied primarily to
> reduce effort (and potential for error). Formal policies also
> provide "cover your ass". One will not be blamed from failures
> when following an approved policy, even if the policy does not
> promote the intended outcomes as well as deviating a little.
> (While forgiveness is often easier to get than permission,
> forgiveness is often dependent on outcome and earlier "forgiven"
> transgressions can be brought back to justify more extreme
> punishment for a later falling short.)
>
> Cookie cutter employees make management easier, especially in
> large organizations. Such also encourages mediocrity, both from
> hiring and internal incentives. Hiring and managing cats is more
> difficult than buying and using cogs — and the latter is not
> trivial.

Yeah.

Re: Misc: Design tradeoffs in virtual memory systems...

<f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32915&group=comp.arch#32915

  copy link   Newsgroups: comp.arch
X-Received: by 2002:ad4:48c4:0:b0:62f:e379:dad5 with SMTP id v4-20020ad448c4000000b0062fe379dad5mr3411940qvx.0.1687441313661;
Thu, 22 Jun 2023 06:41:53 -0700 (PDT)
X-Received: by 2002:aca:db05:0:b0:39e:8f50:89 with SMTP id s5-20020acadb05000000b0039e8f500089mr4154103oig.0.1687441313277;
Thu, 22 Jun 2023 06:41:53 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 22 Jun 2023 06:41:52 -0700 (PDT)
In-Reply-To: <u70li1$377tm$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:cca5:f27c:dd95:1a43;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:cca5:f27c:dd95:1a43
References: <u4por8$3tugb$1@dont-email.me> <2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com> <u677rp$34bhu$1@dont-email.me>
<u6smnf$2gaa7$7@dont-email.me> <u70li1$377tm$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Thu, 22 Jun 2023 13:41:53 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 11528
 by: MitchAlsup - Thu, 22 Jun 2023 13:41 UTC

On Thursday, June 22, 2023 at 12:17:57 AM UTC-5, BGB wrote:
> On 6/20/2023 12:13 PM, Paul A. Clayton wrote:
> > On 6/12/23 9:50 AM, Ivan Godard wrote:
> >> On 6/11/2023 3:48 PM, MitchAlsup wrote:
> >>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
> >>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
> > [snip]
> >>>>> Certainly. But just because someone is clever and does a thing
> >>>>> that does not a) imply that that person is qualified to work at
> >>>>> a higher level, or b) that they are an expert at the thing.
> >
> > I agree and this is one reason I doubt I could provide sufficient
> > value in a tech job. My anxiety, depression, and "not-good-enough-
> > ism" (a.k.a., perfectionism) hinder getting anything done that has
> > the significant potential for significant failure. This hinders
> > even learning about new difficult topics (where failure is more
> > likely), especially when not "just for fun" (failure is not as
> > important with 'games' though it can still be painful).
> >
> Yeah.
>
> I don't get where the whole thing about "claiming to be an expert" was
> coming from; as far as I know, I was doing nothing of the sort.
>
> The whole thing was kind of weird, not sure what was going on exactly,
> but will admit to have been getting rather annoyed about it...
>
>
>
> I was not claiming that I have a particularly solid understanding of
> hypervisors or virtualization, as I was under the (possibly mistaken)
> assumption that they were a sort of hardware-assisted form of emulation:
> Which ironically, was N/A under Soft-TLB both because the TLB is
> flexible enough that the relevant hardware trickery is unnecessary, and
> also low-level enough that the OS level support for virtual memory is
> much closer to what an emulator would do already (since in this case,
> the underlying hardware leaves too much of its "guts" hanging out in the
> open).
>
> But, one could take this as either:
> Hypervisors, in the traditional sense, are N/A;
> Or, alternatively, that the hardware "can't" do a hypervisor due
> providing a level of abstraction that is too low.
>
> Still didn't see too much that was obviously outside the scope of what
> could be handled with the existing mechanisms and some additional lookup
> tables.
>
> Though, at least for emulating x86, the more obvious problem cases are
> more things like condition codes and things like Real-Mode / 16-bit
> PMode / Big-Real Mode. These would likely require either using more
> complex address calculations internally, or needing to add more complex
> logic to the TLB.
>
> The likely more practical option would be to do more complex addressing:
> ADD BaseAddr, SegBase, TmpBase
> LEA.x (TmpBase, Index), TmpBase
> MOV.x (TmpBase, Disp), Dest
>
>
> Though, this would also come with needing to emulate all the PC style
> hardware as well, ...
>
>
> I will still assert, that I was not talking, in any case about a server
> context (and have no idea what exactly a server would using a hypervisor
> for in the first place...).
>
> My understanding was more in the context of things like VMware or
> VirtualBox, which were (IME) typically used for things like running
> older versions of Windows or similar (say, one runs 32-bit WinXP so that
> they can run older games or similar that no longer run on modern 64-bit
> Windows).
>
> But, say, neither of these programs work anymore, so I am mostly limited
> to QEMU and DOSBox (say, a lot of this old software also being old
> enough to run on DOS and/or Win3.11 ...).
>
> In this sense, the difference between "Virtualization" and "Emulation"
> being a bit more abstract, since from the the user perspective both are
> basically doing the same thing (and the performance differences are less
> of an issue, since a modern PC is way faster than what most Win3.x or
> Win9x software was designed for).
>
>
> I can write from experience though, of having used (and written) various
> emulators (and having an idea how it would work on BJX2; just leaving it
> open how to best do it in a way where "the performance doesn't suck").
> > Even if some employer hired me (ignoring my non-work history and
> > psychological issues), I doubt I could be well integrated and
> > productive (doing a good job is important to me). Most managers
> > seem to be mediocre to poor at managing ordinary people and even
> > less skilled at managing "special needs" people. (E.g., most
> > managers do not seem to realize that "X is a good result" could
> > stir more pride and less anxiety than "you did X well". Three of
> > five of the comments on a recently received appreciation card
> > included "keep up the good work", presumably not realizing that
> > such sets up a high baseline for mere acceptance and to be
> > appreciated I have to do even more. Ordinary people would probably
> > receive "keep up the good work" more as "you got this!", i.e., an
> > affirmation.)
> >
> I probably fall in the same category here...
>
> Can't get a job, pretty much anywhere, doing pretty much anything.
> Setting up a machine shop and making parts is at least slightly more
> straightforward.
>
>
> Trying to hold 0.005" on CNC conversion kits on manual machines is a bit
> more of a problem though. More a case of, "Yeah, you will have to be
> happy if it is +/- 0.015 ..."
>
> Like, say, there is a bit of a difference between a "Grizzly Bench-Top
> Mill" (with some steppers bolted on) and a "Haas Machining Center"...
<
Grizzly benchtop might be 300 pounds while the Haas machining center
is closer to 10,000 pounds.
<
I have a Grizzly floor standing mill just over 1,000 pounds and it is not
hard to hit 0.001,5" with good technique. The Haas will hit 0.000,3" every
run.
>
>
> No idea how to make money from either my software or Verilog efforts
> though...
<
There is an old machinist saying:: "You can make anything on a shaper
except money".
<
> > (I have encountered good managers — happily not any truly bad
> > managers, merely some that were not very competent. I also know
> > that managing people is *difficult* and far outside my
> > competencies.)
> >
> My social skills are almost non-existent...
>
>
> But, as noted, I am autistic (Asperger's), seem to have alexithymia, and
> (probably) am also asexual (not confirmed for certain, but evidence
> seems to point this way).
>
> Some other things I had wondered about, but they seem more to be
> side-products of the above, rather than conditions in their own right
> (for example, Alexithymia can also lead to tending towards a
> Machiavellian outlook, but seemingly differs from the "actual" form of
> Machiavellianism in that it doesn't necessarily lead to a desire to act
> in a selfish or exploitative way towards others; more just sort of
> "well, that is how the world works; kinda sucks, just gotta live with
> it", ...).
>
>
> I have realized don't that I don't particularly understand either
> physical or romantic attraction. What I once thought they were, was in
> effect a different emotion; seemingly an adaptation of either
> "autophobia" or "social anxiety" into a form superficially resembling
> some traditional aspects of romantic attraction.
>
> Well, and culturally, it is assumed that one is either physically or
> romantically attracted to someone; not necessarily that a person is
> afraid of the future and essentially wants to use the other person as a
> sort of "security blanket".
>
> But, OTOH, since the way it is portrayed in media often isn't too far
> different, had sort of assumed they are one and the same, and that
> everyone else was effectively experiencing something similar.
>
> But, then one partly gets over the "fear" aspects, and starts to realize
> that they don't actually understand. And, the whole thing starts to seem
> a little abstract (and all I really know is the superficial behaviors
> and social conventions, but not really the meanings of feelings behind
> them).
>
> ...
> > [snip]
> >>> After a few weeks, he ended up being one of our best programmers we
> >>> had EVER hired.
> >>>
> >>> So much for resumés..........
> >
> > Presumably the medical background was not included in the resumé
> > because he did not want to return to that type of work.
> >
> > [snip]
> >
> >> Job prereqs are just a device to let HR be lazy.
> >
> > Any policy (vs. case by case handling) is applied primarily to
> > reduce effort (and potential for error). Formal policies also
> > provide "cover your ass". One will not be blamed from failures
> > when following an approved policy, even if the policy does not
> > promote the intended outcomes as well as deviating a little.
> > (While forgiveness is often easier to get than permission,
> > forgiveness is often dependent on outcome and earlier "forgiven"
> > transgressions can be brought back to justify more extreme
> > punishment for a later falling short.)
> >
> > Cookie cutter employees make management easier, especially in
> > large organizations. Such also encourages mediocrity, both from
> > hiring and internal incentives. Hiring and managing cats is more
> > difficult than buying and using cogs — and the latter is not
> > trivial.
> Yeah.


Click here to read the complete article
Re: Misc: Design tradeoffs in virtual memory systems...

<u71srq$3bqjk$1@dont-email.me>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32916&group=comp.arch#32916

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: cr88192@gmail.com (BGB)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Thu, 22 Jun 2023 11:28:40 -0500
Organization: A noiseless patient Spider
Lines: 299
Message-ID: <u71srq$3bqjk$1@dont-email.me>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u677rp$34bhu$1@dont-email.me> <u6smnf$2gaa7$7@dont-email.me>
<u70li1$377tm$1@dont-email.me>
<f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 22 Jun 2023 16:28:42 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="024e096215e51e110a7f4b97a422cf62";
logging-data="3533428"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+h0H7szQO91fQqscAgjF9+"
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
Thunderbird/102.11.2
Cancel-Lock: sha1:NNiPrQJLgXfRqgB9kmsCC4lE8Vk=
In-Reply-To: <f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com>
Content-Language: en-US
 by: BGB - Thu, 22 Jun 2023 16:28 UTC

On 6/22/2023 8:41 AM, MitchAlsup wrote:
> On Thursday, June 22, 2023 at 12:17:57 AM UTC-5, BGB wrote:
>> On 6/20/2023 12:13 PM, Paul A. Clayton wrote:
>>> On 6/12/23 9:50 AM, Ivan Godard wrote:
>>>> On 6/11/2023 3:48 PM, MitchAlsup wrote:
>>>>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
>>>>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
>>> [snip]
>>>>>>> Certainly. But just because someone is clever and does a thing
>>>>>>> that does not a) imply that that person is qualified to work at
>>>>>>> a higher level, or b) that they are an expert at the thing.
>>>
>>> I agree and this is one reason I doubt I could provide sufficient
>>> value in a tech job. My anxiety, depression, and "not-good-enough-
>>> ism" (a.k.a., perfectionism) hinder getting anything done that has
>>> the significant potential for significant failure. This hinders
>>> even learning about new difficult topics (where failure is more
>>> likely), especially when not "just for fun" (failure is not as
>>> important with 'games' though it can still be painful).
>>>
>> Yeah.
>>
>> I don't get where the whole thing about "claiming to be an expert" was
>> coming from; as far as I know, I was doing nothing of the sort.
>>
>> The whole thing was kind of weird, not sure what was going on exactly,
>> but will admit to have been getting rather annoyed about it...
>>
>>
>>
>> I was not claiming that I have a particularly solid understanding of
>> hypervisors or virtualization, as I was under the (possibly mistaken)
>> assumption that they were a sort of hardware-assisted form of emulation:
>> Which ironically, was N/A under Soft-TLB both because the TLB is
>> flexible enough that the relevant hardware trickery is unnecessary, and
>> also low-level enough that the OS level support for virtual memory is
>> much closer to what an emulator would do already (since in this case,
>> the underlying hardware leaves too much of its "guts" hanging out in the
>> open).
>>
>> But, one could take this as either:
>> Hypervisors, in the traditional sense, are N/A;
>> Or, alternatively, that the hardware "can't" do a hypervisor due
>> providing a level of abstraction that is too low.
>>
>> Still didn't see too much that was obviously outside the scope of what
>> could be handled with the existing mechanisms and some additional lookup
>> tables.
>>
>> Though, at least for emulating x86, the more obvious problem cases are
>> more things like condition codes and things like Real-Mode / 16-bit
>> PMode / Big-Real Mode. These would likely require either using more
>> complex address calculations internally, or needing to add more complex
>> logic to the TLB.
>>
>> The likely more practical option would be to do more complex addressing:
>> ADD BaseAddr, SegBase, TmpBase
>> LEA.x (TmpBase, Index), TmpBase
>> MOV.x (TmpBase, Disp), Dest
>>
>>
>> Though, this would also come with needing to emulate all the PC style
>> hardware as well, ...
>>
>>
>> I will still assert, that I was not talking, in any case about a server
>> context (and have no idea what exactly a server would using a hypervisor
>> for in the first place...).
>>
>> My understanding was more in the context of things like VMware or
>> VirtualBox, which were (IME) typically used for things like running
>> older versions of Windows or similar (say, one runs 32-bit WinXP so that
>> they can run older games or similar that no longer run on modern 64-bit
>> Windows).
>>
>> But, say, neither of these programs work anymore, so I am mostly limited
>> to QEMU and DOSBox (say, a lot of this old software also being old
>> enough to run on DOS and/or Win3.11 ...).
>>
>> In this sense, the difference between "Virtualization" and "Emulation"
>> being a bit more abstract, since from the the user perspective both are
>> basically doing the same thing (and the performance differences are less
>> of an issue, since a modern PC is way faster than what most Win3.x or
>> Win9x software was designed for).
>>
>>
>> I can write from experience though, of having used (and written) various
>> emulators (and having an idea how it would work on BJX2; just leaving it
>> open how to best do it in a way where "the performance doesn't suck").
>>> Even if some employer hired me (ignoring my non-work history and
>>> psychological issues), I doubt I could be well integrated and
>>> productive (doing a good job is important to me). Most managers
>>> seem to be mediocre to poor at managing ordinary people and even
>>> less skilled at managing "special needs" people. (E.g., most
>>> managers do not seem to realize that "X is a good result" could
>>> stir more pride and less anxiety than "you did X well". Three of
>>> five of the comments on a recently received appreciation card
>>> included "keep up the good work", presumably not realizing that
>>> such sets up a high baseline for mere acceptance and to be
>>> appreciated I have to do even more. Ordinary people would probably
>>> receive "keep up the good work" more as "you got this!", i.e., an
>>> affirmation.)
>>>
>> I probably fall in the same category here...
>>
>> Can't get a job, pretty much anywhere, doing pretty much anything.
>> Setting up a machine shop and making parts is at least slightly more
>> straightforward.
>>
>>
>> Trying to hold 0.005" on CNC conversion kits on manual machines is a bit
>> more of a problem though. More a case of, "Yeah, you will have to be
>> happy if it is +/- 0.015 ..."
>>
>> Like, say, there is a bit of a difference between a "Grizzly Bench-Top
>> Mill" (with some steppers bolted on) and a "Haas Machining Center"...
> <
> Grizzly benchtop might be 300 pounds while the Haas machining center
> is closer to 10,000 pounds.
> <
> I have a Grizzly floor standing mill just over 1,000 pounds and it is not
> hard to hit 0.001,5" with good technique. The Haas will hit 0.000,3" every
> run.

Yeah. In this case, it is a Grizzly G0704 on a stand.

X and Y axis are using NEMA23 steppers with half-stepping and a 2:1
reduction.

Z axis is using a NEMA34 direct-drive.

Originally, it was NEMA23 with a 3:1 reduction (with the original
leadscrew), but a NEMA34 was used here as a replacement. Sorta had to
set the stepper driver to its max setting (6A/ph), as the driver can't
really do the full rated 8A/ph of the motor (basically works, though the
Z axis max speed is set fairly low).

In both cases, the original 10 TPI leadscrews were replaced with 5 TPI
ballscrews. Base, saddle, and the bottom of the mill table were modded
slightly to create clearance for the ballscrews, with adapters made out
of blocks of aluminum.

X axis seems "mostly OK" in terms of travel. In this case, the ballscrew
is secured on both ends with bearings and nuts.

Y axis seems to have backlash, but in the design the Y axis only has a
single bearing at one end of the ballscrew (where the other end is
"hanging in the breeze").

Not sure, I suspect the backlash may be possibly due either into
possible "play" in the mounting block or in the bearing.

It was a lot better at first, but backlash started showing up "after the
fact".

There is also an old Bridgeport that was previously sitting outside for
a long time, but "not entirely rusted away". Also has steppers and
ballscrews, but still hit or miss in some areas.

There is also an old ShopTask combo machine (using a replacement
controller, namely a 2005 era PC running LinuxCNC), but this has the
disadvantages of both poor travel distances and particularly bad
backlash (in the area of ~ 0.030"...). Had tightened the gibs and
similar vs what it was originally (more of a "table is so loose one can
visibly push it back and forth by hand" thing).

Also an ER collet adapter that has seemingly somehow gotten permanently
fused into the R8 holder (past attempts to undo the drawbar and knock it
loose having been unsuccessful).

Both the Bridgeport and ShopTask machines were essentially "salvage"
that people had left outside rusting in the rain for probably years.

....

>>
>>
>> No idea how to make money from either my software or Verilog efforts
>> though...
> <
> There is an old machinist saying:: "You can make anything on a shaper
> except money".
> <


Click here to read the complete article
Re: Misc: Design tradeoffs in virtual memory systems...

<bi0lM.28942$k4z1.26276@fx17.iad>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32917&group=comp.arch#32917

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!1.us.feeder.erje.net!feeder.erje.net!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer02.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx17.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: scott@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Newsgroups: comp.arch
References: <u4por8$3tugb$1@dont-email.me> <2023May28.165701@mips.complang.tuwien.ac.at> <u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me> <u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me> <eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com> <u677rp$34bhu$1@dont-email.me> <u6smnf$2gaa7$7@dont-email.me> <u70li1$377tm$1@dont-email.me> <f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com> <u71srq$3bqjk$1@dont-email.me>
Lines: 29
Message-ID: <bi0lM.28942$k4z1.26276@fx17.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Thu, 22 Jun 2023 18:20:55 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Thu, 22 Jun 2023 18:20:55 GMT
X-Received-Bytes: 2216
 by: Scott Lurndal - Thu, 22 Jun 2023 18:20 UTC

BGB <cr88192@gmail.com> writes:
>On 6/22/2023 8:41 AM, MitchAlsup wrote:
>> On Thursday, June 22, 2023 at 12:17:57 AM UTC-5, BGB wrote:

>Did see a video recently where someone was basically claiming that FOSS
>/ Open Source is basically a dead-end, given the whole issue that the
>original developers tend not to be able to earn a living from it, and
>pretty much everyone using the software (if they use it) is not usually
>inclined to put any money towards sponsoring the original developers.

That's been a common theme since Eric Raymond stopped by SGI back
in the last century to pitch open source. SGI had already
been contributing to linux at that point (I had contributed the
in-kernel debugger KDB).

I'm quite happy with the results of my subsequent investment in
RedHat stock when they IPO'd slightly thereafter.

>
>But, then it is a case of, well, if I asked money for any of this, who
>would use it. People would just be like "meh whatever" and go and use
>something else instead (that they could get for free).

Yeah. IBM (Redhat), Ubuntu, SUSE certainly havn't made any money off open source.
(very tongue in cheek).

Most open source contributors also have day jobs.

Re: Misc: Design tradeoffs in virtual memory systems...

<32227a59-5945-4ff9-bcc1-3c31b5068e84n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32918&group=comp.arch#32918

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:6214:4a47:b0:62e:3c97:dd7a with SMTP id ph7-20020a0562144a4700b0062e3c97dd7amr3326902qvb.9.1687473142655;
Thu, 22 Jun 2023 15:32:22 -0700 (PDT)
X-Received: by 2002:a05:6830:4784:b0:6af:a3de:5d26 with SMTP id
df4-20020a056830478400b006afa3de5d26mr4040862otb.7.1687473142389; Thu, 22 Jun
2023 15:32:22 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.goja.nl.eu.org!3.eu.feeder.erje.net!2.eu.feeder.erje.net!feeder.erje.net!fdn.fr!proxad.net!feeder1-2.proxad.net!209.85.160.216.MISMATCH!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 22 Jun 2023 15:32:22 -0700 (PDT)
In-Reply-To: <u71srq$3bqjk$1@dont-email.me>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:d890:a891:1240:228;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:d890:a891:1240:228
References: <u4por8$3tugb$1@dont-email.me> <2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com> <u677rp$34bhu$1@dont-email.me>
<u6smnf$2gaa7$7@dont-email.me> <u70li1$377tm$1@dont-email.me>
<f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com> <u71srq$3bqjk$1@dont-email.me>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <32227a59-5945-4ff9-bcc1-3c31b5068e84n@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Thu, 22 Jun 2023 22:32:22 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
 by: MitchAlsup - Thu, 22 Jun 2023 22:32 UTC

On Thursday, June 22, 2023 at 11:28:46 AM UTC-5, BGB wrote:
> On 6/22/2023 8:41 AM, MitchAlsup wrote:
> > On Thursday, June 22, 2023 at 12:17:57 AM UTC-5, BGB wrote:
> >> On 6/20/2023 12:13 PM, Paul A. Clayton wrote:
> >>> On 6/12/23 9:50 AM, Ivan Godard wrote:
> >>>> On 6/11/2023 3:48 PM, MitchAlsup wrote:
> >>>>> On Monday, June 5, 2023 at 6:34:40 AM UTC-5, Ivan Godard wrote:
> >>>>>> On 6/5/2023 4:12 AM, Dan Cross wrote:
> >>> [snip]
> >>>>>>> Certainly. But just because someone is clever and does a thing
> >>>>>>> that does not a) imply that that person is qualified to work at
> >>>>>>> a higher level, or b) that they are an expert at the thing.
> >>>
> >>> I agree and this is one reason I doubt I could provide sufficient
> >>> value in a tech job. My anxiety, depression, and "not-good-enough-
> >>> ism" (a.k.a., perfectionism) hinder getting anything done that has
> >>> the significant potential for significant failure. This hinders
> >>> even learning about new difficult topics (where failure is more
> >>> likely), especially when not "just for fun" (failure is not as
> >>> important with 'games' though it can still be painful).
> >>>
> >> Yeah.
> >>
> >> I don't get where the whole thing about "claiming to be an expert" was
> >> coming from; as far as I know, I was doing nothing of the sort.
> >>
> >> The whole thing was kind of weird, not sure what was going on exactly,
> >> but will admit to have been getting rather annoyed about it...
> >>
> >>
> >>
> >> I was not claiming that I have a particularly solid understanding of
> >> hypervisors or virtualization, as I was under the (possibly mistaken)
> >> assumption that they were a sort of hardware-assisted form of emulation:
> >> Which ironically, was N/A under Soft-TLB both because the TLB is
> >> flexible enough that the relevant hardware trickery is unnecessary, and
> >> also low-level enough that the OS level support for virtual memory is
> >> much closer to what an emulator would do already (since in this case,
> >> the underlying hardware leaves too much of its "guts" hanging out in the
> >> open).
> >>
> >> But, one could take this as either:
> >> Hypervisors, in the traditional sense, are N/A;
> >> Or, alternatively, that the hardware "can't" do a hypervisor due
> >> providing a level of abstraction that is too low.
> >>
> >> Still didn't see too much that was obviously outside the scope of what
> >> could be handled with the existing mechanisms and some additional lookup
> >> tables.
> >>
> >> Though, at least for emulating x86, the more obvious problem cases are
> >> more things like condition codes and things like Real-Mode / 16-bit
> >> PMode / Big-Real Mode. These would likely require either using more
> >> complex address calculations internally, or needing to add more complex
> >> logic to the TLB.
> >>
> >> The likely more practical option would be to do more complex addressing:
> >> ADD BaseAddr, SegBase, TmpBase
> >> LEA.x (TmpBase, Index), TmpBase
> >> MOV.x (TmpBase, Disp), Dest
> >>
> >>
> >> Though, this would also come with needing to emulate all the PC style
> >> hardware as well, ...
> >>
> >>
> >> I will still assert, that I was not talking, in any case about a server
> >> context (and have no idea what exactly a server would using a hypervisor
> >> for in the first place...).
> >>
> >> My understanding was more in the context of things like VMware or
> >> VirtualBox, which were (IME) typically used for things like running
> >> older versions of Windows or similar (say, one runs 32-bit WinXP so that
> >> they can run older games or similar that no longer run on modern 64-bit
> >> Windows).
> >>
> >> But, say, neither of these programs work anymore, so I am mostly limited
> >> to QEMU and DOSBox (say, a lot of this old software also being old
> >> enough to run on DOS and/or Win3.11 ...).
> >>
> >> In this sense, the difference between "Virtualization" and "Emulation"
> >> being a bit more abstract, since from the the user perspective both are
> >> basically doing the same thing (and the performance differences are less
> >> of an issue, since a modern PC is way faster than what most Win3.x or
> >> Win9x software was designed for).
> >>
> >>
> >> I can write from experience though, of having used (and written) various
> >> emulators (and having an idea how it would work on BJX2; just leaving it
> >> open how to best do it in a way where "the performance doesn't suck").
> >>> Even if some employer hired me (ignoring my non-work history and
> >>> psychological issues), I doubt I could be well integrated and
> >>> productive (doing a good job is important to me). Most managers
> >>> seem to be mediocre to poor at managing ordinary people and even
> >>> less skilled at managing "special needs" people. (E.g., most
> >>> managers do not seem to realize that "X is a good result" could
> >>> stir more pride and less anxiety than "you did X well". Three of
> >>> five of the comments on a recently received appreciation card
> >>> included "keep up the good work", presumably not realizing that
> >>> such sets up a high baseline for mere acceptance and to be
> >>> appreciated I have to do even more. Ordinary people would probably
> >>> receive "keep up the good work" more as "you got this!", i.e., an
> >>> affirmation.)
> >>>
> >> I probably fall in the same category here...
> >>
> >> Can't get a job, pretty much anywhere, doing pretty much anything.
> >> Setting up a machine shop and making parts is at least slightly more
> >> straightforward.
> >>
> >>
> >> Trying to hold 0.005" on CNC conversion kits on manual machines is a bit
> >> more of a problem though. More a case of, "Yeah, you will have to be
> >> happy if it is +/- 0.015 ..."
> >>
> >> Like, say, there is a bit of a difference between a "Grizzly Bench-Top
> >> Mill" (with some steppers bolted on) and a "Haas Machining Center"...
> > <
> > Grizzly benchtop might be 300 pounds while the Haas machining center
> > is closer to 10,000 pounds.
> > <
> > I have a Grizzly floor standing mill just over 1,000 pounds and it is not
> > hard to hit 0.001,5" with good technique. The Haas will hit 0.000,3" every
> > run.
> Yeah. In this case, it is a Grizzly G0704 on a stand.
>
> X and Y axis are using NEMA23 steppers with half-stepping and a 2:1
> reduction.
>
> Z axis is using a NEMA34 direct-drive.
>
> Originally, it was NEMA23 with a 3:1 reduction (with the original
> leadscrew), but a NEMA34 was used here as a replacement. Sorta had to
> set the stepper driver to its max setting (6A/ph), as the driver can't
> really do the full rated 8A/ph of the motor (basically works, though the
> Z axis max speed is set fairly low).
>
>
> In both cases, the original 10 TPI leadscrews were replaced with 5 TPI
> ballscrews. Base, saddle, and the bottom of the mill table were modded
> slightly to create clearance for the ballscrews, with adapters made out
> of blocks of aluminum.
>
> X axis seems "mostly OK" in terms of travel. In this case, the ballscrew
> is secured on both ends with bearings and nuts.
>
>
> Y axis seems to have backlash, but in the design the Y axis only has a
> single bearing at one end of the ballscrew (where the other end is
> "hanging in the breeze").
>
> Not sure, I suspect the backlash may be possibly due either into
> possible "play" in the mounting block or in the bearing.
<
Backlash does not matter if you perform the final setting always from the
same direction. In my case I always approach the operation by moving the
table to the left or towards the "neck" of the machine. So If I have to position
to the right of where I am, I go farther than needed (by 0.050) and then back
up. This puts all the backlash in the same direction, and nulls it out.
>
> It was a lot better at first, but backlash started showing up "after the
> fact".
>
Change the programming to simply eliminate dependence on lack
of backlash.
>
> There is also an old Bridgeport that was previously sitting outside for
> a long time, but "not entirely rusted away". Also has steppers and
> ballscrews, but still hit or miss in some areas.
>
>
> There is also an old ShopTask combo machine (using a replacement
> controller, namely a 2005 era PC running LinuxCNC), but this has the
> disadvantages of both poor travel distances and particularly bad
> backlash (in the area of ~ 0.030"...). Had tightened the gibs and
> similar vs what it was originally (more of a "table is so loose one can
> visibly push it back and forth by hand" thing).
>
> Also an ER collet adapter that has seemingly somehow gotten permanently
> fused into the R8 holder (past attempts to undo the drawbar and knock it
> loose having been unsuccessful).
<
Remove the spindle nut and take a 1/2" steel rod and bang it out from the top.
{{Apply generous amounts of penetrating oil the night before.}}
>
> Both the Bridgeport and ShopTask machines were essentially "salvage"
> that people had left outside rusting in the rain for probably years.
>
> ...
> >>
> >>
> >> No idea how to make money from either my software or Verilog efforts
> >> though...
> > <
> > There is an old machinist saying:: "You can make anything on a shaper
> > except money".
> > <
> Did see a video recently where someone was basically claiming that FOSS
> / Open Source is basically a dead-end, given the whole issue that the
> original developers tend not to be able to earn a living from it, and
> pretty much everyone using the software (if they use it) is not usually
> inclined to put any money towards sponsoring the original developers.
<
Happens in ALL hobbies...........nobody can make any money of them
and continue development until they loose interest.
>
> But, then it is a case of, well, if I asked money for any of this, who
> would use it. People would just be like "meh whatever" and go and use
> something else instead (that they could get for free).
>
> Well, and if someone puts something under GPL, most people using it in
> embedded systems are just like "meh whatever" and don't bother complying
> with the GPL and releasing their own code or modifications under the GPL
> (and the embedded system manufacturers keep any profits to themselves).
>
>
> Seemingly the only real "profitable" area for independent developers is
> things like games, and only really if it "goes viral" (and this
> typically only lasts for a short time). Otherwise, they tend to have a
> relatively short shelf-life (before pretty much everyone forgets about
> it and moves onto the next thing); with neither quality nor technical
> merit mattering all that much in this space it seems.
<
The profit for me is the satisfaction of intellectual development.
>


Click here to read the complete article
Re: Misc: Design tradeoffs in virtual memory systems...

<u73bpr$3grjc$1@newsreader4.netcologne.de>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=32920&group=comp.arch#32920

  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-f9e9-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de!not-for-mail
From: tkoenig@netcologne.de (Thomas Koenig)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Fri, 23 Jun 2023 05:49:47 -0000 (UTC)
Organization: news.netcologne.de
Distribution: world
Message-ID: <u73bpr$3grjc$1@newsreader4.netcologne.de>
References: <u4por8$3tugb$1@dont-email.me>
<2023May28.165701@mips.complang.tuwien.ac.at>
<u52uav$ngk$1@reader2.panix.com> <u5ifdv$s3i$1@dont-email.me>
<u5kfvq$j4s$1@reader1.panix.com> <u5kh8c$ap5s$1@dont-email.me>
<eac774d4-5d39-4365-84db-1bf9df7f11d7n@googlegroups.com>
<u677rp$34bhu$1@dont-email.me> <u6smnf$2gaa7$7@dont-email.me>
<u70li1$377tm$1@dont-email.me>
<f921d20b-3fbf-4526-879b-29fbb6697d7cn@googlegroups.com>
<u71srq$3bqjk$1@dont-email.me> <bi0lM.28942$k4z1.26276@fx17.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Injection-Date: Fri, 23 Jun 2023 05:49:47 -0000 (UTC)
Injection-Info: newsreader4.netcologne.de; posting-host="2001-4dd4-f9e9-0-7285-c2ff-fe6c-992d.ipv6dyn.netcologne.de:2001:4dd4:f9e9:0:7285:c2ff:fe6c:992d";
logging-data="3698284"; mail-complaints-to="abuse@netcologne.de"
User-Agent: slrn/1.0.3 (Linux)
 by: Thomas Koenig - Fri, 23 Jun 2023 05:49 UTC

Scott Lurndal <scott@slp53.sl.home> schrieb:
> BGB <cr88192@gmail.com> writes:
>>On 6/22/2023 8:41 AM, MitchAlsup wrote:
>>> On Thursday, June 22, 2023 at 12:17:57 AM UTC-5, BGB wrote:
>
>
>>Did see a video recently where someone was basically claiming that FOSS
>>/ Open Source is basically a dead-end, given the whole issue that the
>>original developers tend not to be able to earn a living from it, and
>>pretty much everyone using the software (if they use it) is not usually
>>inclined to put any money towards sponsoring the original developers.
>
> That's been a common theme since Eric Raymond stopped by SGI back
> in the last century to pitch open source. SGI had already
> been contributing to linux at that point (I had contributed the
> in-kernel debugger KDB).
>
> I'm quite happy with the results of my subsequent investment in
> RedHat stock when they IPO'd slightly thereafter.
>
>>
>>But, then it is a case of, well, if I asked money for any of this, who
>>would use it. People would just be like "meh whatever" and go and use
>>something else instead (that they could get for free).
>
> Yeah. IBM (Redhat), Ubuntu, SUSE certainly havn't made any money off open source.
> (very tongue in cheek).
>
> Most open source contributors also have day jobs.

Unless you're SUSE or Redhat, which sell packages, it is quite
hard to get paid for open source development.

GCC, which is big and complex and requires quite a few FTEs, is
mostly done by people who get paid by their respective employers.
gfortran is a little Gaulish village mostly done by volunteers,
with the exception offloading, where Siemens is currently investing
some employee time. Lack of funding has severely hindered gfortran
development, but there are plans to supply for public funding at
the moment.

OpenFOAM is another critical piece of open-source infrastructure
which is struggling to meet its rather modest financing goals,
given its prevalence in universities and now also industry (after
graduates with experience in that package have moved there).

Re: Misc: Design tradeoffs in virtual memory systems...

<86v8eexuei.fsf@linuxsc.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=33314&group=comp.arch#33314

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: tr.17687@z991.linuxsc.com (Tim Rentsch)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Thu, 20 Jul 2023 12:19:49 -0700
Organization: A noiseless patient Spider
Lines: 10
Message-ID: <86v8eexuei.fsf@linuxsc.com>
References: <u4por8$3tugb$1@dont-email.me> <Ia3cM.3440031$iU59.2338510@fx14.iad> <u4qntf$1fqa$1@dont-email.me> <PT6cM.355159$eRZ7.6952@fx06.iad>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: dont-email.me; posting-host="3857442d865f8a7bff3454fde02b814b";
logging-data="2993568"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX195uEnxxgry9OVpBH2DlEswotHgufD26VI="
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux)
Cancel-Lock: sha1:qN8HhdNHvZ1K0P4JxE4nwGKrd3w=
sha1:Q2awVT4c7slKCax7asbLPQh8pjE=
 by: Tim Rentsch - Thu, 20 Jul 2023 19:19 UTC

scott@slp53.sl.home (Scott Lurndal) writes:

[...]

> Unlike the CPUs below, x86 and arm are continuously
> being enhanced with new features (e.g. secure conclaves,
> realms, new instructions, etc). [...]

I expect you mean secure enclaves, not conclaves.

Re: Misc: Design tradeoffs in virtual memory systems...

<702a09d4-c595-4131-93d5-6fd3bdc4b1a9n@googlegroups.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=33316&group=comp.arch#33316

  copy link   Newsgroups: comp.arch
X-Received: by 2002:a05:622a:1a1d:b0:3f6:b052:3431 with SMTP id f29-20020a05622a1a1d00b003f6b0523431mr75qtb.5.1689881346880;
Thu, 20 Jul 2023 12:29:06 -0700 (PDT)
X-Received: by 2002:a05:6808:1315:b0:3a4:87eb:da2c with SMTP id
y21-20020a056808131500b003a487ebda2cmr1174520oiv.0.1689881346742; Thu, 20 Jul
2023 12:29:06 -0700 (PDT)
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer03.iad!feed-me.highwinds-media.com!news.highwinds-media.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.arch
Date: Thu, 20 Jul 2023 12:29:06 -0700 (PDT)
In-Reply-To: <86v8eexuei.fsf@linuxsc.com>
Injection-Info: google-groups.googlegroups.com; posting-host=2600:1700:291:29f0:5174:e76e:14d2:9184;
posting-account=H_G_JQkAAADS6onOMb-dqvUozKse7mcM
NNTP-Posting-Host: 2600:1700:291:29f0:5174:e76e:14d2:9184
References: <u4por8$3tugb$1@dont-email.me> <Ia3cM.3440031$iU59.2338510@fx14.iad>
<u4qntf$1fqa$1@dont-email.me> <PT6cM.355159$eRZ7.6952@fx06.iad> <86v8eexuei.fsf@linuxsc.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <702a09d4-c595-4131-93d5-6fd3bdc4b1a9n@googlegroups.com>
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
From: MitchAlsup@aol.com (MitchAlsup)
Injection-Date: Thu, 20 Jul 2023 19:29:06 +0000
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Received-Bytes: 1855
 by: MitchAlsup - Thu, 20 Jul 2023 19:29 UTC

On Thursday, July 20, 2023 at 2:19:53 PM UTC-5, Tim Rentsch wrote:
> sc...@slp53.sl.home (Scott Lurndal) writes:
>
> [...]
>
> > Unlike the CPUs below, x86 and arm are continuously
> > being enhanced with new features (e.g. secure conclaves,
> > realms, new instructions, etc). [...]
>
> I expect you mean secure enclaves, not conclaves.
<
Enclaves I will buy, secure I won't--after all they are still subject
to meltdown and Spectré attack strategies after being given 7
years to address them.

Re: Misc: Design tradeoffs in virtual memory systems...

<u9c1uq$2rlb$1@gal.iecc.com>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=33317&group=comp.arch#33317

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!weretis.net!feeder6.news.weretis.net!news.cmpublishers.com!adore2!news.iecc.com!.POSTED.news.iecc.com!not-for-mail
From: johnl@taugh.com (John Levine)
Newsgroups: comp.arch
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Date: Thu, 20 Jul 2023 19:29:30 -0000 (UTC)
Organization: Taughannock Networks
Message-ID: <u9c1uq$2rlb$1@gal.iecc.com>
References: <u4por8$3tugb$1@dont-email.me> <u4qntf$1fqa$1@dont-email.me> <PT6cM.355159$eRZ7.6952@fx06.iad> <86v8eexuei.fsf@linuxsc.com>
Injection-Date: Thu, 20 Jul 2023 19:29:30 -0000 (UTC)
Injection-Info: gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970";
logging-data="93867"; mail-complaints-to="abuse@iecc.com"
In-Reply-To: <u4por8$3tugb$1@dont-email.me> <u4qntf$1fqa$1@dont-email.me> <PT6cM.355159$eRZ7.6952@fx06.iad> <86v8eexuei.fsf@linuxsc.com>
Cleverness: some
X-Newsreader: trn 4.0-test77 (Sep 1, 2010)
Originator: johnl@iecc.com (John Levine)
 by: John Levine - Thu, 20 Jul 2023 19:29 UTC

According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>scott@slp53.sl.home (Scott Lurndal) writes:
>
>[...]
>
>> Unlike the CPUs below, x86 and arm are continuously
>> being enhanced with new features (e.g. secure conclaves,
>> realms, new instructions, etc). [...]
>
>I expect you mean secure enclaves, not conclaves.

I like the secure conclaves, with teeny tiny priests in itsy bitsy
black hoods chanting the secret keys.

--
Regards,
John Levine, johnl@taugh.com, Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. https://jl.ly

Re: Misc: Design tradeoffs in virtual memory systems...

<8gwuM.10046$O8ab.7306@fx40.iad>

  copy mid

https://news.novabbs.org/devel/article-flat.php?id=33353&group=comp.arch#33353

  copy link   Newsgroups: comp.arch
Path: i2pn2.org!i2pn.org!usenet.blueworldhosting.com!diablo1.usenet.blueworldhosting.com!peer01.iad!feed-me.highwinds-media.com!news.highwinds-media.com!fx40.iad.POSTED!not-for-mail
X-newsreader: xrn 9.03-beta-14-64bit
Sender: scott@dragon.sl.home (Scott Lurndal)
From: scott@slp53.sl.home (Scott Lurndal)
Reply-To: slp53@pacbell.net
Subject: Re: Misc: Design tradeoffs in virtual memory systems...
Newsgroups: comp.arch
References: <u4por8$3tugb$1@dont-email.me> <u4qntf$1fqa$1@dont-email.me> <PT6cM.355159$eRZ7.6952@fx06.iad> <86v8eexuei.fsf@linuxsc.com> <u9c1uq$2rlb$1@gal.iecc.com>
Lines: 22
Message-ID: <8gwuM.10046$O8ab.7306@fx40.iad>
X-Complaints-To: abuse@usenetserver.com
NNTP-Posting-Date: Fri, 21 Jul 2023 14:04:52 UTC
Organization: UsenetServer - www.usenetserver.com
Date: Fri, 21 Jul 2023 14:04:52 GMT
X-Received-Bytes: 1299
 by: Scott Lurndal - Fri, 21 Jul 2023 14:04 UTC

John Levine <johnl@taugh.com> writes:
>According to Tim Rentsch <tr.17687@z991.linuxsc.com>:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>
>>[...]
>>
>>> Unlike the CPUs below, x86 and arm are continuously
>>> being enhanced with new features (e.g. secure conclaves,
>>> realms, new instructions, etc). [...]
>>
>>I expect you mean secure enclaves, not conclaves.

Yes. Had been reading ACM recently:

https://dl.acm.org/doi/10.1145/3302424.3303982

>
>I like the secure conclaves, with teeny tiny priests in itsy bitsy
>black hoods chanting the secret keys.
>

Snort!

Pages:12345678
server_pubkey.txt

rocksolid light 0.9.8
clearnet tor