From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) by sourceware.org (Postfix) with ESMTPS id 2EE683858D28 for ; Tue, 29 Aug 2023 01:14:56 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2EE683858D28 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=linux-m68k.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=linux-m68k.org Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id E3CE13200986; Mon, 28 Aug 2023 21:14:54 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 28 Aug 2023 21:14:55 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; t=1693271694; x=1693358094; bh=GYzaHF4EoQJrl jrwW7H1vltFJPOCwd8O8DL1nWVnf5s=; b=ldn5edeb4zJttOVrqFCdPEcA6O4jv 5mBpMHCZxEl6FPIaJhXXgIfBAXeyiwA89QyqtPwsq6P8ogK8hbZBubeFUAhcyXfE /4x8tkGcom+HB/9y/2EmFEr4j3zW8rXJXbblD52GDWyBmR2FSqMk4xgYUf1JiZt2 xQ9OaaC78PYU7iRtS6/lpDg7AizcUec7vD9DwCByq/QDcrO07Aqw9QOVsm/FO8nT uDyxLanfxj0d4WczOREVMo0ePhU+4G1lA9SNfWPbbW6GLFVIFyKeuXQV7bIbGHly PG3FYiK6sRabAjFyg5oVExjkufnZ7dvjpFLLQvst449pv+EnD52oxC2ow== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrudefhedggeefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepfffhvfevufgjkfhfgggtsehttdertddttddvnecuhfhrohhmpefhihhnnhcu vfhhrghinhcuoehfthhhrghinheslhhinhhugidqmheikehkrdhorhhgqeenucggtffrrg htthgvrhhnpeelueehleehkefgueevtdevteejkefhffekfeffffdtgfejveekgeefvdeu heeuleenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe hfthhhrghinheslhhinhhugidqmheikehkrdhorhhg X-ME-Proxy: Feedback-ID: i58a146ae:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 28 Aug 2023 21:14:50 -0400 (EDT) Date: Tue, 29 Aug 2023 11:14:48 +1000 (AEST) From: Finn Thain To: John Paul Adrian Glaubitz cc: James Le Cuirot , libc-help@sourceware.org, debian-68k , linux-m68k Subject: Re: Tuple and changes for m68k with -malign-int In-Reply-To: <4b4fe9c56dfdb8ec74150413cfc211d70243eb7e.camel@physik.fu-berlin.de> Message-ID: <0891ec11-bed1-9120-79d5-4436dc9aee32@linux-m68k.org> References: <10cbcb8a65639f88e7eeb503fd02df172bc46a07.camel@physik.fu-berlin.de> <80a52487-3105-ed5b-a1eb-ec1a0689ef21@linux-m68k.org> <4b4fe9c56dfdb8ec74150413cfc211d70243eb7e.camel@physik.fu-berlin.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Mon, 28 Aug 2023, John Paul Adrian Glaubitz wrote: > > And since we have to break the ABI anyway to be able to use 64-bit > time_t If you're worried about Y2038, aren't you jumping the gun? I reckon we have about 10 years in which to figure out what a better m68k ABI should look like. > I don't see any valid reason to stick to the problematic 16-bit > alignment used by the current ABI. > Well, here are a few reasons why all those padding patches you wrote were a good thing (besides the obvious benefit of avoiding an ABI break): - That code is now more portable among projects which care about portability to 16-bit platforms etc. - Explicit alignment reveals suboptimal cache footprint and wasted memory. - Data structures often outlive the software that introduced them. It's safe to say that the struct definitions you fixed will produce a benefit you may never hear about, by virtue of code re-use. > ... > > If it's the former, perhaps you should not push it upstream. If it's > > the latter, perhaps this redesign should seek to address real > > shortcomings with the existing ABI, including problems which (for all > > I know) may have entirely prevented some people from using it thus > > far. That is, it should consider silicon beyond 680x0. > > It's a historic architecture. We don't have to redesign everything. Coldfire is still shipping (is it "historic" yet?). Not sure about Apollo 68080 and Buffee BP68040. Most likely TG68K and Pistorm will end up gaining whatever features Linux requires (MMU etc.). If we get the ABI right, such designs can benefit if it allows them to go beyond 680x0 and better exploit the FPGA they may be implemented on. (Dare I mention SMP?) Considering just Coldfire for a moment, one question we could look at is, how could the ABI be changed to permit the same binaries to work efficiently on both kernels (CF and 680x0)? It seems likely that ABI changes could potentially help to accelerate 68k emulators. Inefficient thread local storage is an issue that might be addressed with VDSO calls rather than an ABI break.