Sujet : Re: Continuations
De : cr88192 (at) *nospam* gmail.com (BGB)
Groupes : comp.archDate : 14. Jul 2024, 21:59:14
Autres entêtes
Organisation : A noiseless patient Spider
Message-ID : <v71e73$aaos$2@dont-email.me>
References : 1 2
User-Agent : Mozilla Thunderbird
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