Date: Fri, 13 Feb 2015 22:48:39 +1100 (EST) From: Ian Smith <smithi@nimnet.asn.au> To: Don Lewis <truckman@freebsd.org> Cc: erichsfreebsdlist@alogt.com, freebsd-stable@freebsd.org, allbery.b@gmail.com, kpneal@pobox.com Subject: Re: top, fixed buffer length in utils.c Message-ID: <20150213215013.B38620@sola.nimnet.asn.au> In-Reply-To: <201502130833.t1D8XPkI036074@gw.catspoiler.org> References: <201502130833.t1D8XPkI036074@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 13 Feb 2015 08:33:25 -0800, Don Lewis wrote: > On 13 Feb, Brandon Allbery wrote: > > On Thu, Feb 12, 2015 at 10:50 PM, <kpneal@pobox.com> wrote: > > > >> The case where int varies in size between platforms is distinct from the > >> case where int varies in size between compilers on the same platform. If > >> you reread what I wrote you'll see that I was addressing the latter case. > >> > > > > C++ at least defines platform ABIs starting with C++11. If ANSI C does not > > now, I suspect it will --- interoperability issues have come up before (for > > example, in the early x86 days there were differences between how C > > compilers packed structs. And in the *very* early x86 days there were > > differences between compilers in the exact details of (int) and (long) and > > pointer types in different memory models) and the result is that these days > > there is usually (but not always) a de facto ABI for a platform. > > At least that's somewhat sane. My first real exposure to C was on a > machine where int was 24 bits. I think short was as well. Long, float, > and double were all 48 bits as I recall. Char was 8 bits, so having > three chars in a word made char * arithmetic interesting. At least it > could use ASCII. Porting "normal" software to that machine was lots of > fun. > > If it would have had 6-bit characters like a machine that I used in my > pre-C days would have made pointer arithmetic easier because four > characters would have fit in a word, but that machine actually had > 36-bit words. So far as I know, it never got a C compiler. I'm finding this drawn-out speculation kind of amusing. My first real systems programming job was converting hundreds of data files from NCR 315 to IBM S/360|370 format for $largemultinational in Sydney C. 1971. The NCR315 was a 12-bit machine (32k 12-bit 'slabs' of real core memory) and the shiny new IBM S/370-145 (64k of 32-bit, DTL|TTL tech IIRC) where the NCR used 6 bit chars (uppercase only), 2 per slab and numbers were all BCD, 3 per slab, to the IBM's 8-bit EBCDIC chars and mostly BCD numbers, no floats at least in the data files these subsidiaries used. What was most fun was that the NCR wrote 7-track paper or mag tape, the standard IBM used 9-track mag or paper tape, so we had to dig up and write (what we would call) drivers for a 7-track paper tape reader and some fairly generic file format conversion programs, some of which had to be postproccessed to newer formats. Data file conversion took many months, longer than connversion/rewriting of mostly COBOL programs, most having a goodly number of added assembler fixes in their 'patch area'. The highest level language on the S/370 was then PL/I. If there was anything happening in C for those machines, I never heard about it; systems programming was macro assembly language all the way. I even left keeping an assembler listing of the /370's (what we would call) kernel, over 2 inches of 15-inch fanfold paper, but it got eaten by rainforest moulds and bugs in the late '70s. I still kinda miss it! Off-topic? I expect it's almost de rigeur for this thread .. <&^}= cheers, Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150213215013.B38620>