Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Continuations
Date: Sun, 14 Jul 2024 15:59:06 -0500
Organization: A noiseless patient Spider
Lines: 112
Message-ID: <v71e6t$aaos$1@dont-email.me>
References: <v6tbki$3g9rg$1@dont-email.me>
 <memo.20240713174208.14216G@jgd.cix.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Sun, 14 Jul 2024 22:59:10 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a46f72ab884f872e3d901e51e664c05d";
	logging-data="338716"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19kiti+YWmVoPGiBvzoJBQX/O3XmI0F2fM="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:zAyenUpKCqAeP64t7HZGkvynV+U=
In-Reply-To: <memo.20240713174208.14216G@jgd.cix.co.uk>
Content-Language: en-US
Bytes: 5257

On 7/13/2024 11:42 AM, John Dallman wrote:
> In article <v6tbki$3g9rg$1@dont-email.me>, ldo@nz.invalid (Lawrence
> D'Oliveiro) wrote:
> 
>> The beauty of continuations is that they are a single generalized
>> control construct that can be used to implement specific language
>> features like regular routine calls, loops, exceptions and
>> coroutines, all built from the same common abstraction. One thing
>> that is difficult to do with them is arbitrary gotos. (I consider
>> that a feature, not a bug.)
> 
> Just occasionally, you need a goto to get out of a complicated error
> situation. Not often, but sometimes.
> 

Yes.

> I'm also of the opinion that unless memory gets a lot faster, requiring
> hardware to maintain and navigate data structures in memory is a bad idea.
> They'll get used because they're there, but they'll be slow. One can't
> avoid page tables, but they should be simple.
> 

One can avoid needing page tables in hardware via software manage TLB 
(for better or worse):
   Pros:
     Cheaper hardware (in terms of logic);
     More flexible.
   Cons:
     Potentially worse performance;
     Switching address spaces takes a bigger performance hit;
     More complicated for OS.

I had generally noted that for the main TLB, one generally needs at 
least 4-way associativity to get acceptable results with a SW TLB.

Putting a TLB in the L1 caches, one can use a 1-way TLB to good effect 
(provided these can fall back to a bigger TLB if their local TLB misses).

Potentially a page-walker could get along OK with a smaller TLB and 
1-way or 2-way associativity (partly offsetting the cost of the mechanism).


Though, it seems like it may be a slightly different situation if one 
assumes cheap logic and expensive SRAM, in this case a hardware page 
walker may be preferable since it may be able to give acceptable 
performance with a comparably smaller TLB.

Seems also like a priority in this case to try to optimize things to 
minimize memory requirements:
Say, trying to keep data compact to limit the amount of external memory 
IO, possibly trying to get along with less memory bandwidth and smaller 
caches, ...


Say, we might be facing a future where people drop back to 8K or 16K 
L1's because 32K or 64K is too expensive?...

Though, in my testing, 32K seems to be "near optimal" (dropping smaller, 
miss rate increases more significantly, and 64K is twice the cost for 
relatively little reduction in miss rate). Dropping back to 16K is 
possible, but 8K or less would have a steep impact.

My perennial "try to boost core to 75MHz" thing seemingly invariably 
runs into the problem of whatever compromises I make to try to make the 
faster clock speed possible comes at the cost of making overall 
execution slower to a point where it eats any gains.





Otherwise, recently I have gone and sorta gotten "Quake 3 Arena" ported 
to BJX2, though it still needs a lot of debugging (and has apparently 
been stepping on a lot of bugs).

Also performance is "not so good".

But, at least maybe this will beat some bugs out of my compiler. Some 
recent examples:

Subtracting unsigned integers from pointers was broken;
   Would perform an unsigned negate,
   which would make the pointer off by 4+GB ...

By value structs were/are internally handled using references, which 
broke when trying to use struct assignment to swap two structs in 
arrays. Ended up needing to make assignment to a local variable always 
use by-copy semantics, which is slower but does seem to fix the behavior 
in this case.

   temp=a[i];
   a[i]=a[j];
   a[j]=temp;

Prior semantics would effectively perform two struct copies, giving 
incorrect results as 'temp' now no longer had the correct contents when 
the 3rd line was executed.

A lot of the other code I had ported hadn't really used struct 
assignment this way, so it got missed (and then its main effect was that 
is was causing Bezier patches to get messed up).


Still some other longstanding bugs that have not been figured out (it 
being easier to figure out bugs when the effects are more obvious).

....


> John