From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,MAILING_LIST_MULTI,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 3800 invoked from network); 8 Jun 2023 15:06:04 -0000 Received: from minnie.tuhs.org (2600:3c01:e000:146::1) by inbox.vuxu.org with ESMTPUTF8; 8 Jun 2023 15:06:04 -0000 Received: from minnie.tuhs.org (localhost [IPv6:::1]) by minnie.tuhs.org (Postfix) with ESMTP id 6A43B4001F; Fri, 9 Jun 2023 01:05:59 +1000 (AEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tuhs.org; s=dkim; t=1686236759; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-owner:list-unsubscribe:list-subscribe:list-post; bh=S5ecqQJYGog9lA3slSE98IDw1tSP5P8S+UBvhP0kf9s=; b=lWRyBJ7d3fseIPLGwwXehlcPOR5zUJQMS9d63l0uqhvCxCcPZv7agfloR5lljKgv6rwnJ6 gdTp6VXcDyqEfrWUfT1mn47gCt7gY/gvMtsP/CmUj+8kgTudWL96fti8vmIyCi/N/L+20Y X0SLFvtDOq779EUYUpUVEEEUlWfMkPc= Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by minnie.tuhs.org (Postfix) with ESMTPS id 1159F40BAA for ; Fri, 9 Jun 2023 01:05:52 +1000 (AEST) Date: Thu, 08 Jun 2023 15:05:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1686236748; x=1686495948; bh=S5ecqQJYGog9lA3slSE98IDw1tSP5P8S+UBvhP0kf9s=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=XWozRsCDxKpPOfzRYWCtOfK1Ov9SkzSgQ0gNMPSacEYwg0Q7wrkbLR0iJ0o1MydBW AMfQqoUKe6DO3bxH7JjvGI8qaUUWL9FKzVWgIIbpIR5ZihG0AK8Zcf3+R3LNWl/YfB 9PoqatvVZU8gCX8TpEVV4Geq3F50SmAywcxKvBm+cEaVHjNOY5S8DF0DAYUD90F442 rlECJhFKFrq6vaa/CmHHEyOBH/4XzTQeQEk0WNdQJ94woLcW6K7KAXs3cALx35Oh3F fF01MVWWqvHUfWCBS3eHcJer3M9H1/6UvEmeZ+dQSEwQPjUd5XNlP26WjXX1LpRJGx yW9wh9IO5oYPQ== To: Phil Budne Message-ID: In-Reply-To: <202306080331.3583Vrw7057546@ultimate.com> References: <1e651370-3ada-e211-c277-409d6563500d@f4grx.net> <202306080331.3583Vrw7057546@ultimate.com> Feedback-ID: 35591162:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID-Hash: PACTJRELCGZRDARB26MXGORTETXV2SBK X-Message-ID-Hash: PACTJRELCGZRDARB26MXGORTETXV2SBK X-MailFrom: segaloco@protonmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: tuhs@tuhs.org X-Mailman-Version: 3.3.6b1 Precedence: list Subject: [TUHS] Re: Software written in B List-Id: The Unix Heritage Society mailing list Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: From: segaloco via TUHS Reply-To: segaloco > The signature I would expect from binary B code of this era would be > that the generated code from each source file starts with a branch (or > jmp) around the contents of the file, to a "jsr r5, chain" followed by > a zero terminated list of addresses (which I guessed were addresses of > address words that needed to be fixed up). Looking a little closer I think that is what this is, because each file is = an a.out header, then a jmp, followed by what I presume is B object code, t= hen the destination of the jmp at that jsr r5 that passes into a routine th= at I think is then what handles that 0-terminated table of address words. = All of the files have a similar bit up to the data word this opening proces= s increments, so I suspect those are the bounds of brt1, from the opening v= ector (that the header of the B object jumps to) to the data flag that gets= set by the inc operation. My assumption is that the B objects were stamped with a jmp that simply jum= ped to whatever the first address past the end was, so then brt1 had to be = physically right there to accept flow. After that point the remaining bits= in the B files aren't as similar, but what I can say is I don't see anythi= ng on the tail end of these binaries that is consistent enough between them= to peg as a brt2. Instead each seems to be a slightly different jumble of= interpreter routines themselves. At least I think, this is a very high le= vel assessment though, I haven't fully broken any of these into individual = parts yet. By the way, one characteristic of this supposed brt1 code is that it checks= that the first word after the jump in the B object is 40022(8) (which is t= he in-core address of the next word in the B object btw). If it is not pre= sent, or the B runtime did not set the data flag indicated above as the end= of brt1, then it simply prints "Init\n" on stdout and exits. Only if both= this B "magic number" and the flag indicating proper entry are set does it= seem to proceed rather than just printing Init and exiting. Not sure what this means, or what the reasoning behind this behavior is, bu= t that explains the "Init" string in each binary, it is also part of the B = runtime. - Matt G.