Received: by 2002:a05:6a10:2785:0:0:0:0 with SMTP id ia5csp2952226pxb; Tue, 12 Jan 2021 02:42:08 -0800 (PST) X-Google-Smtp-Source: ABdhPJzZADa2zsNtaCjh+KXLnBblnDQIkNVHv/cEJlnPPPAtPNL3MDc+lITlJlMxib8Dc7+dnx3N X-Received: by 2002:aa7:ca14:: with SMTP id y20mr2871176eds.340.1610448128305; Tue, 12 Jan 2021 02:42:08 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1610448128; cv=none; d=google.com; s=arc-20160816; b=rk6C0YAHEl3GioEUtwTr8ZUOFDV03MbvFBq56C8WH1QRJhb3KaRfUdwM4daflOJEd7 vlWqh6VY7NOVK2OrjaBfwLjmh+QIGiHgPXKRElQndC9Yks0DVMugNxeYAcF0yI1jmP92 QlQ95ojkB5kkUfowvm5lmPHQCw6pTYwLfgmgXZnTgU2FaDHYiqEw9ieiW7j3heNUCfEi UtZJ0sVmKmiXLbFIBUQ4/u0Yx+0hHFvHAxcXIDkfv2ymies7DmYaNeSiSYOdWstE2lu7 /VBXHU5izPYO5y8yd3jHHHQ7xI6lfxQR8Ry5a0IlDGSwyi/4KwX+VW2SkijmJsh/JPM3 DktA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature; bh=G5DIxSZetsXeR2X3GAYIsmKuc4e0LX+pB1h8al42nGA=; b=aSl7gZ5AR8tCYAXCpiPFrZS+nZUTJJ4t0heBzTZDxbgOM4fXbl/CPUg5VzjZI22qr1 XRL5dzalkrwahOjRSoUQIbR0ANpbqUyw1IzvVE6zICu+guv6mSPd7xgEWNssj+TZs2j1 NB+05jZj3bJ1aU9gn+FM1uPAhcl7ihcP3lOofSzXS/baWklXYktbpgObBoQKKpLyoX4z X+CxKIZrfzMXMYltqReahqSMhtXoPdx16gJfIWuiBw9couuK1RrY/fTtLQ1ajf3XrmkO XdJ/YNFdY/ACkYARo8e+JkzQLkkgMEUCS6Yzw7NRHAEzeY78bFvOLQddb9kca60EySNR CVbg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j+w8cAPm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id r23si1141563edw.310.2021.01.12.02.41.44; Tue, 12 Jan 2021 02:42:08 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@gmail.com header.s=20161025 header.b=j+w8cAPm; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=gmail.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728857AbhALAvl (ORCPT + 99 others); Mon, 11 Jan 2021 19:51:41 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:58846 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727995AbhALAvk (ORCPT ); Mon, 11 Jan 2021 19:51:40 -0500 Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AE7FEC061575; Mon, 11 Jan 2021 16:50:59 -0800 (PST) Received: by mail-ej1-x62b.google.com with SMTP id d17so1026190ejy.9; Mon, 11 Jan 2021 16:50:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=G5DIxSZetsXeR2X3GAYIsmKuc4e0LX+pB1h8al42nGA=; b=j+w8cAPmi1ouSNkB0JqJUkdXD2VJoqYoycV8eQYOpVz5VF8TwAYOQnJu4l6qSpe1TP l7cC9+RmbUcKXbqnWzgLDa+qn60MdYylKKNyOM2Y3aYHPOqg45Q7c2vcm5mofHVVOnWW BhwCQrkXbjWXz4C7+VJWYTGrFCHl2Onjd1rasxY4Tze0mPYJnVEeqWVwXrnP3jFbtpAG hhy+ITv2iGARdXt0IgayP4e7IkWKy/y1Qv/3GkoDzqJUyn1XKHXO+0D83Mz/Xr/TEUEd ee7W91Ay8q4dNbSafyg4ABdEc88Nh6n9FXIKHIe77FLIeiDzpDJ2KT9ADfJFVO1SEbQo KrsQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=G5DIxSZetsXeR2X3GAYIsmKuc4e0LX+pB1h8al42nGA=; b=cOUhRoc7NRNwlcEQZls6MRmBkwzFyvk5ArEZ4mPfezciLavdZ6fTzaBmsU5TaA5kBd 6mYaJmX4gfJ3CYEflQbP7tCma0wNP8hp4JcZ7YtcU9qm/A7e2vfo2AhV9eQhiQpSXoTS S15+r7SiY1X1ZvgRSOcRMDWYAYKrk5UnvGgo5c4U3kzwi20B+NuUvujtb/P6rOe3bKOD Hs2klR5nOTrzc4meT2te+pvx15hgvYUXHdBRMK0mbJ6Oqmf8LvKbY7Yfg5eeZFQmdDap ZrSTC1Bv/ObLVUEFshCm7Y9dWYTBqYRC/BNh3YX4CFw6F+iuUjMaSzw0sadzqMujySlj VZlQ== X-Gm-Message-State: AOAM533DctozyEpwyuf0BW8nb2itWlLwvtubQVT3Z6iDAFRW/fmh4XxE JazHxXIfNOisDxZjddBsD8FOoixlsYBumIwESsISUvapTus= X-Received: by 2002:a17:906:7c49:: with SMTP id g9mr1408341ejp.185.1610412658411; Mon, 11 Jan 2021 16:50:58 -0800 (PST) MIME-Version: 1.0 References: <20210110214653.GA1693373@ravnborg.org> <1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net> In-Reply-To: <1f6e936c-4947-4952-fae2-c05d03e0cd2c@landley.net> From: chase rayfield Date: Mon, 11 Jan 2021 19:50:48 -0500 Message-ID: Subject: Re: Old platforms: bring out your dead To: Rob Landley Cc: John Paul Adrian Glaubitz , Sam Ravnborg , Arnd Bergmann , Linux Kernel Mailing List , linux-m68k , Sparc kernel list , Linux-sh list Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Sparc has a runtime relocation I've never understood but did manage to break > once, resulting in a long thread to fix: > > http://lists.landley.net/pipermail/aboriginal-landley.net/2011-December/001964.html > > Between that and the weird save half the stack register thing with function > calls on some sort of "wheel"... there's a _reason_ I haven't been able to talk > Rich into adding support for it to musl. > Register windowing, with parts of each window overlapping for function arguments etc... you can kind of think of it as a ring buffer of overlapping register files that's an oversimplification but it was originally intended to accelerate and improve register file usage. MIPS and the rest of the industry abandoned this for improved compile time allocation. I think you might be more likely on MIPS to incur more interrupt latency though since you have to spill to memory (at least on MIPS contemporary to Sparc V8) instead of just switching register windows mileage varies greatly.... From what I remember overflowing the register file is implemented with hardware traps that spill to memory etc... since you don't know that information at compile time. on Sparc so yeah it's quite involved to understand and I certainly don't grasp it fully. So on MIPS you spill the register file to memory, on Sparc you spill register windows to memory... if you have exceeded the supported call depth (which is rather expensive since all the register windows go at once). Note spilling a single variable within a register window is a separate issue. Amazing, a link that actually works and is informative: https://blogs.oracle.com/d/flush-register-windows Chase