Re: Continuations

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