Path: ...!weretis.net!feeder8.news.weretis.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:14 -0500
Organization: A noiseless patient Spider
Lines: 62
Message-ID: <v71e73$aaos$2@dont-email.me>
References: <v6tbki$3g9rg$1@dont-email.me>
 <47689j5gbdg2runh3t7oq2thodmfkalno6@4ax.com>
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:16 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a46f72ab884f872e3d901e51e664c05d";
	logging-data="338716"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19kxwSpnjEKYT6Uapu/jpgrEV3KQFC5AVU="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:ZKANAcdmenOP3/lCXWeYd+APvdM=
In-Reply-To: <47689j5gbdg2runh3t7oq2thodmfkalno6@4ax.com>
Content-Language: en-US
Bytes: 3315

On 7/14/2024 1:31 PM, John Savard wrote:
> On Sat, 13 Jul 2024 07:50:42 -0000 (UTC), Lawrence D'Oliveiro
> <ldo@nz.invalid> wrote:
> 
>> One thing that is difficult to do with them
>> is arbitrary gotos. (I consider that a feature, not a bug.)
> 
> It's a bug.
> If a programming language wants to disallow arbitrary gotos in order
> to promote better quality code writing, that's great.
> But the machine language of a computer has got to allow _any_ language
> to be implemented on it. Including C, or old-style FORTRAN.
> Otherwise, one doesn't have a general-purpose machine.
> 

This was one major annoyance I had about WASM:
They tried to structure their IR around high-level control flow 
constructs rather than ye olde labels and goto; which (as a compiler 
target) somewhat hinders its usability.

Granted, WASM was designed to be able to be decoded to run on 
conventional JS VMs, where JavaScript typically lacks goto, so, ...


OTOH: In my stack IR's, an if-goto oriented model was used, and I had 
tended instead to make labels a special instruction, which effectively 
encode: "Control flow may land here with this ID.". Branch instructions 
typically encoded the ID of the label they wanted to branch to (rather 
than a byte offset or similar).

This approach seemed to make more sense for IRs, and labels as an 
instruction basically signaled where to break up the code into basic-blocks.



But, yeah, I still have skepticism about the viability of a continuation 
based ABI.

Best I can think of for an ABI at the moment might be something like:
   .retry:
   MOV.Q  (TBR, xx), R18     //Frame free-list
   MOV.Q  (R18, index), R19  //Get frame of appropriate size
   TSTQ   R19, R19           //check if pointer is NULL
   BF     .noalloc
   // save LR and registers specially, then allocate more frames
   // restores initial registers when done
   BRA    .retry
   .noalloc:
   MOV.Q  (R19, 0), R1       //put next frame into free-list
   MOV.Q  R1, (R18, index)
   //now we can start the prolog proper...


Where, the freelist would be based on index numbers for what size call 
frame is needed.

But, in any case, this is going to be slower than:
   ADD -disp, SP


> John Savard