On 09/17/2015 11:19 PM, Guy Sotomayor wrote: OK, thanks, I knew there was this patch RAM, but didn't know the purpose. Jon

On Fri, Sep 18, 2015 at 06:58:24AM -0400, Mouse wrote: I've been told this more than a few times and read it in various places. It always make me wonder, could we not allow a mode in modern Intel processors that lets us bypass the x86 code emulation/translation and run "directly on the metal" (if there were such a thing). The purpose, of course, would be to gain performance. Certainly this would already have been done if there was any significant gain to be had? /P

On 18 September 2015 at 13:35, Lars Brinkhoff <lars at nocrew.org> wrote: [[Citation needed]] I've never heard of anything like this. Are you perhaps thinking of the Crusoe family chips? -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 09/18/2015 11:00 AM, Lars Brinkhoff wrote: Too bad--I've got a couple of C3 systems here that might be fun to experiment with... (very common processor to find on older thin clients) --Chuck

On 18 September 2015 at 13:06, Pontus Pihlgren <pontus at update.uu.se> wrote: I think not, because the "RISC core interpreting x86 instructions" is a fairly gross over-simplification, as best as I have been able to determine. Yes, all C21 x86 chips borrow lots of design principles lot of fancy on-the-fly optimisations. There isn't an underlying separate different microcode. That has been done, though. It was the Transmeta Crusoe line of processors. These were not directly x86-compatible at all: they had their own instruction set, and during boot, loaded a translation layer on top which executed x86 code via a sort of optimising compiler/interpreter with JIT. The purpose was to achieve very low power consumption, for portables. The performance was not as good as native x86 even at the time -- although nearly -- but the processors used significantly less power. They were not RISC, though: they were VLIW underneath. I always thought it was *the* critical mistake of Transmeta not to at least release the native instruction set. If they could also execute Motorola 680x0 code, or PowerPC code, or Alpha code, or any other discontinued (or effectively discontinued) instruction set, they would still have a market today. -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

Just a quick history of x86 implementation styles (from memory, so don't take this very seriously): 8086: Intel's first pipeline, with separate Fetch and Execution units iAPX286: borrowed some ideas from iAPX432's protection model, but I don't know any implementation details 386: traditional CISC pipeline 486: main "RISC" pipeline for most popular instructions wih microcode support for the rest (some of the least popular instructions were actually slower than on the 386) Pentium: dual "RISC" pipelines, one of which had microcode support for the rest of the instructions Nx586 from NextGen: internal RISC instruction set with hardware translation from x86 Pentium Pro: like Nx586 (internal instructions called "micro ops") K6 from AMD: AMD bought NextGen and updated their technology Pentium II and III: improved Pentium Pro Pentium 4: the "microburst" architecture was optimized for highest possible clocks. The hardware translator for x86 to micro ops was placed before the instruction cache instead of after, which allowed some interesting optimizations Core, Core 2 and so on: though at first sight it seems like the x86 instructions are translated into RISC "micro ops", the internal execution engine is actually a DataFlow machine instead. This is called out of order (OOO) execution and the reason this isn't obvious is because the bits that link the instructions together are spread out among different hardware parts and not all together with the instructions themselves as in classical DataFlow architectures. Having direct access to this internal OOO engine would not really help. Being able to bypass it entirely could be interesting since it takes a lot of energy and transistors to do its job, and this is what the Mill architecture is trying to do: http://millcomputing.com/docs/ -- Jecel

Yes...but. The first objection that occurs to me is that it's reasonably likely the "underlying RISC core" is not a very good general-purpose machine. That's what the "(designed for and)" was alluding to: the underlying machine, to the extent that there is one, is designed for running exactly one thing, that being the x86 emulator. It would, for example, not surprise me if it did not have the user/kernel privilege mode distinction that approximately all OSes depend on these days. Others have also raised the point that doing this would require the vendor to document and support the underlying machine. This is only somewhat true, but it's doubtless at least part of the explanation. (The documentation probably exists, for internal use if nothing else, but likely contains things the vendor is unwilling to release. I don't recall details, but I recall thinking, in reaction to a vendor leak, that it might have been the vendor wanting to release documentation but wanting to retain plausible deniability about having done so....) And, of course, there are probably other forces at work too. But it's still annoying and disappointing that only the letter agencies and the black-hat community are competent to rewrite the microcode in modern peecees. (Well, and the vendors, of course.) I just recently (mostly-)finished transcribing the VAX architecture manual into text (I am doing final proofreading before letting the result out; I'll announce it here once I have it ready). One of the subsections says | C.3.1 Publishing Architecture Discrepancies | | The Systems Architecture group maintains the lists of known | architecture discrepancies. These lists are made available to ARG | members for distribution within their organizations. The lists are | submitted to publications that are readily accessible to customers if | the discrepancies are visible to customers. All discrepancies that | have been waived will be published in the architecture specification, | either as a note in an appropriate section, or in an appendix for | waivers. | | The single exception is that we will not publish the list of "system | killers" outside of Digital. All questions about "system killers", | even ones asking if there are any, will be answered "No Comment". The | reason for this is to protect customers (from their users) by | providing absolutely no information on the subject. In addition, this | "no comment" policy will be published along with the lists of | architecture discrepancies. This evidences a vast faith - now shown to be misplaced - in the inability of the black hats to discover things without DEC's help; the notion that such a policy _would_ protect customers from their users depends on DEC being the only source of such information. My point here is not to reawaken the "full disclosure" question; it's just that it would not surprise me if -- no, it would surprise me if not -- there were a component of this attitude in modern CPU vendors' failure to release documentation on the real hardware, despite all the history showing that such policies just give the black hats an advantage.... /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

As far as I know, the VAX11/730 (There is one next to me waiting for me to have time to restore it) has the microcode entirely in RAM. Classic PERQs (3 in the next room) have their microcode entirely in RAM too (in that case, there is a microcode boot ROM to load the microcode from disk, but it is switched out after the microcode is loaded). -tony

"Self modifying code may seem like a neat idea. But, it will turn around and byte you in the arse. Maybe not now, but soon, and for the rest of your life."

The 11/780 has a PDP11 to load the microcode (I think) but the 11/730 makes do with an 8085. After booting I think that handles the console port still. -tony

On 2015-09-18 18:21, Jon Elson wrote: The normal WCS option for the 11/780 was an option. Not everyone had it. Were there another option with some WCS that actually everybody had? Johnny

On Fri, Sep 18, 2015 at 7:45 AM, tony duell <ard at p850ug1.demon.co.uk> wrote: Most of the 11/780 microcode is in bipolar PROM. There's a small patch area which is loaded by the PDP-11. The 11/785 microcode is entirely in RAM, so it all gets loaded by the PDP-11.

On 2015-09-18 15:45, tony duell wrote: The VAX-11/78x had some microcode on a floppy. Not sure if it was required in order to run the machine, or if just a few select bits and pieces were on that floppy. It's been way too many years since I touched those machines. Maybe someone else will know? The VAX-11/750 have the microcode in rom, but it has a system by which you can patch the microcode. There is some ram, but not enough to hold all the microcode. You you can "overwrite" selected addresses of the microcode, and this was/is used both by VMS, Ultrix and NetBSD to fix a few bugs in the machine. The VAX-11/730 would have to have the microcode on TU58, as that is the console media. Quite possible that it actually do load the microcode many ways... :-) The VAX-86x0 machines have the microcode on the front-end RL02. All of it. You want a copy? :-) Johnny

On 9/18/2015 9:51 PM, tony duell wrote: Simple answer. The control store functionality had to fit in the available space on one hex sized card, and 16K density DRAM was the only option. Allocating additional space to use 4K or 1K SRAM would have pushed the CPU design to an additional board, which was not a design option at the time. Don

On 9/18/2015 10:15 PM, tony duell wrote: Yes it was released in mid--1982 (that is correct) but the architecture started in 1977 and the first proto was built in 1979. By 1980 the design was finalized and multiple copies were being built and distributed to software development. Documented here: http://bitsavers.trailing-edge.com/pdf/dec/vax/730/memos/730_Business_Plan_… Page 8 has a detailed timeline. So the 730 was implemented based on the technology available in late 79 or so. The biggest risk I remember from the 730 design (I worked in the same hardware lab, different project: 11/74 CIS) was the extensive use of PALs. This was the first (I believe) project at DEC to use them, and they were basically buying all the devices MMI could produce. It was one of the limiting factors determining the number of prototypes that could be built. Other projects (like the one I was working on) wanted to use PALs, but we couldn't because they were all allocated to the 730 project.

On 9/18/2015 7:33 AM, tony duell wrote: VAX and PREQ's are not something I go to Wallmart and pick up for $147.95 with some bread and T-shirts. Ben.

On 18/09/2015 14:33, tony duell wrote: Is an overlay self modifyig code? Rod -- Wanted : KDJ11-E M8981 KK8-E M8300 KK8-E M8310 KK8-E M8320 KK8-E M8330

On 19/09/2015 14:03, Paul Koning wrote: Its a while back but I seem to remember in BASIC you replaced a set of line numbers with another of the same range but different code. Rod -- Wanted : KDJ11-E M8981 KK8-E M8300 KK8-E M8310 KK8-E M8320 KK8-E M8330

On 2015-09-19 1:15 PM, Liam Proven wrote: Thank God nobody would build such a thing into a modern language, especially not the one that runs in almost every browser... --Toby

On 19 September 2015 at 19:45, Toby Thain <toby at telegraphics.com.au> wrote: Well, quite. :-) Or rather, :-( -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 19 September 2015 at 19:53, tony duell <ard at p850ug1.demon.co.uk> wrote: OK, that I've seen, yes. Even, very carefully, used it. But the examples I've seen do not behave as you describe. Note, I am not saying it's impossible or never happens, merely that it does not match the behaviour I've seen. In ever BASIC interpreter I've ever used, the LOAD command loads a new program in from $MEDIUM. This implicitly gets rid of the program previously in memory. It is not the same as a NEW command, which usually also resets all variables etc. If you want to keep the existing program in memory *and* load additional lines from storage, there was a different command: MERGE. But in everything from ZX BASIC to BBC BASIC to GWBASIC, loading a program erases all lines of code in interpreter RAM and replaces the whole program with the one loaded from disk, but leaves variables etc. intact. This means that, in effect, the program modules being loaded are overlays: you can pass state (a whole set of initialised variables and their values) from one module of code to another. I maintained a large MS-DOS payroll program written this way: it consisted of 18-30+ sub-64kB modules of code. (How many depended on the client's requirements.) The first module initialised all the variables in memory and drew a menu. The menu LOADed the other modules, many of which LOADed each other to handle the task. All the variables remaining in place in RAM, all effectively globals, as GW-BASIC didn't offer local variables, named procedures etc. The reason was that you couldn't have a program of >64kB on GW-BASIC. The original developer taught me to think of each chunk as a procedure, and all the variables as globals. The code was extensively commented to explain what variables it expected to find in place, what they held, which ones it would modify etc. Once I understood it, I found it really elegant. I don't think I've *ever* seen a program that MERGEd in code during execution, though. That sounds terrifying! Nifty! -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 20 September 2015 at 13:54, Peter Coghlan <cctalk at beyondthepale.ie> wrote: Hmmm. I'm now wondering if the command was CHAIN not LOAD... -- Liam Proven ? Profile: http://lproven.livejournal.com/profile Email: lproven at cix.co.uk ? GMail/G+/Twitter/Flickr/Facebook: lproven MSN: lproven at hotmail.com ? Skype/AIM/Yahoo/LinkedIn: liamproven Cell/Mobiles: +44 7939-087884 (UK) ? +420 702 829 053 (?R)

On 09/20/2015 09:00 AM, Peter Coghlan wrote: Some BASICs implement a type of COMMON (to borrow from FORTRAN) which contains variables for communication between CHAINed program units. In that respect, CHAINed programs behave much more like overlays, albeit all as level (0,0). I'm not certain that any BASICs implement the FORTRAN-style overlay hierarchy. --Chuck

On 09/21/2015 02:24 AM, Johnny Billquist wrote: That's true--but a first encounter with the notion, at least for me, involved FORTRAN, not any language. For example, consider that in the CDC FTN reference, overlays are put ahead of I/O. http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/lang/fortran/601… PDF page 77 et seq. I did say that the CHAIN statement was the equivalent of overlaying the (0,0) overlay and perhaps the above reference shows what I mean. COBOL also used overlays, and they were part of the standard language and worked somewhat differently. See http://bitsavers.informatik.uni-stuttgart.de/pdf/cdc/cyber/lang/cobol/60191… PDF page 73 et seq. I do know what the BASIC CHAIN statement means. In the early 80s, I headed a team that implemented a multi-user commercial BASIC on an 8085 micro system, eventually migrated to XENIX and was in use in some places up until a few years ago. I still have a couple of the design documents in my files--as well as the mandatory (for then) t-shirt and coffee mug. One of the lessons I learned from the experience is that compilation to native machine code does not always result in faster code than P-code implementations. --Chuck

On 09/21/2015 11:49 AM, Mouse wrote: Probably a misspeak. But FORTRAN is more than simply a language--it's a way of life. :) The gist was that the notion of an overlay tree was first brought to my notice with FORTRAN. It could be that it had been presented in earlier documents as such and evaded my notice., It did take the form of a set of subroutine calls, and was not an element of standard FORTRAN. As mentioned, COBOL had a similar scheme that was embedded in the language itself. --Chuck

On 09/21/2015 12:18 PM, Fred Cisin wrote: Conversely, several languages were initially written in FORTRAN--it was among the most portable in the early days. Remember those programs that started out with a statement something like this? C FIRST, GET THE CHARACTER SET DIMENSION IALPHA(80) READ 100,IALPHA 100 FORMAT (80A1) Not everyone spoke USASCII or EBCDIC back in the day--and character constants weren't part of most FORTRANs. --Chuck

On 09/21/2015 01:37 PM, Dave G4UGM wrote: PASCAL was first implemented in FORTRAN. --Chuck

On 09/21/2015 02:58 PM, Paul Koning wrote: Well, that was a wink-wink-nudge-nudge statement from yours truly. Wirth & Co. started the project in FORTRAN, but gave up, particularly when it was realized that implementing data structures and recursion in FORTRAN was going to be a bit of a task. I think the result was bootstrapped. I've got a copy of the ETH CDC compiler from 1976, bearing Urs Amann's name as the author. It isn't exactly Pascal, either. But if the issue really was data structures, maybe COBOL would have been a better choice. I do recall that there was at least an Algol-60 compiler on CDC iron at that time. --Chuck

On 09/21/2015 06:23 PM, Mouse wrote: Wirth and Co. didn't invent P-code. I worked with a fellow who did a P-code implementation of COBOL back in the 60s (it ran in a 6600 PP). --Chuck

If you wanted portability then Fortran or Cobol were pretty much all you had. Whilst there may have been C compilers you probably didn't have one, certainly in the world of commerce. Which is why our X.25 code was in Fortran.. On Sep 22, 2015 1:41 AM, "Toby Thain" <toby at telegraphics.com.au> wrote:

On 9/22/2015 12:11 PM, Chuck Guzis wrote: PL/M in FORTRAN made CP/M possible. That to me seems more important than Pascal in Fortran. Ben.

On 9/22/2015 1:49 PM, Chuck Guzis wrote: I can't think of OS's off hand but CP/M and Flex. Mr Gates Basic does not count as OS. True, but the Cross Assembler still would be FORTRAN. The only hand coded machine would have been the APPLE I. Only now I have money to play with small computers (FPGA 8 bit design) not in the late 70's. I suspect the high cost of hardware left little money left for software was true for every one back then.

On Tue, 22 Sep 2015, Chuck Guzis wrote: Wouldn't an F77 programmer be looking for Fortran, not FORTRAN? Ah, yes. I remember WatFor I hadn't been using FORTRAN long when I was thrown into PDQ FORTRAN.

On Tue, 22 Sep 2015, Chuck Guzis wrote: Thanks. I mixed up 77 and 90. Although I was assigned to TEACH F77 in the early 1980s, I was no longer using FORTRAN. WHAT?? You can input and output without FORMAT??!?

On Tue, Sep 22, 2015 at 01:07:14PM -0700, Fred Cisin wrote: And Unix was no different, 'C' started out as a Fortran compiler. -- - db at FreeBSD.org db at db.net http://www.db.net/~db

On Tue, Sep 22, 2015 at 04:35:24PM -0400, Paul Koning wrote: http://www.princeton.edu/~hos/Mahoney/expotape.htm https://web.archive.org/web/20030501014008/http://cm.bell-labs.com/who/dmr/… Diane -- - db at FreeBSD.org db at db.net http://www.db.net/~db

I agree; AFAIK I was never aware of any link between Fortran and early C ... although if you squint at Ratfor just the right way it looks at times a little bit like K&R without C-style function declarations and calling semantics and some of the other frosting... I could see this being the root of the assumption of the link between the two? Best, Sean On Tue, Sep 22, 2015 at 5:22 PM, Jay Jaeger <cube1 at charter.net> wrote:

On 09/22/2015 06:31 PM, Jon Elson wrote: Which is why C started out with a COMPLEX data type...NOT. FORTRAN can run on a much wider variety of machines than can C. C was nothing more than a bare step up from assembly. --Chuck

On 09/22/2015 07:11 PM, Jay Jaeger wrote: We've been here before and I don't care to chew already masticated cud. Suffice it to say, that I've never seen a C for a non-binary, variable-word-length machine using 6-bit characters. I've seen plenty of FORTRANs for such an architecture, however. --Chuck

On 09/22/2015 09:06 PM, Jay Jaeger wrote: Look, I can probably implement a C compiler (or FORTRAN or GPSS or JOVIAL or...) in Brainf*ck. But a 1401 C would very likely be ill-suited to solving numeric problems compared to FORTRAN on the same platform. Which is the point. I suppose that it's possible to implement graphics manipulation routines in RPG II. After all, languages are supposed to expose features of the underlying machine to the programmer. If that weren't the case, we'd all be writing machine code. Languages don't do anything in and of themselves. You can write gibberish in any computer language. Similarly, you can also write code that solves problems. The argument is one of ease, not ability. --Chuck

On 09/23/2015 01:39 AM, ANDY HOLT wrote: And I take your point. At least on supercomputers, it has pretty much been the pattern that vast amounts of code are spent on automatic optimization. There seems to be a situation where computers implement a set of features that allow for higher performance, but then the HLL has to have some way to express the use of these features. SIMD instructions can be very difficult to abstract. Initially, it's usually done through a subroutine/function library, then incorporated into the code generation and optimization. Then, the language committee haggles and comes up with language structures. Take F90, for example. One of the major focii of the effort was to incorporate vector extensions into the language. But how to cover the most ground and yet come up with something that a non-vector machine can do justice to. Whatever you come up with, it must be intelligible to humans (recall that the standard has a broad definition of "computer", which includes humans). Whatever the new extensions do, they must also not break the syntax and meaning of the already existing base language. So you have to have language features to define vectors of varying shapes, operations of various strides, control structures (e.g. sparse vectors, control vectors, etc.). This can engender some furious battles. I recall that IBM threatened to withdraw from X3J3 if its Vectran extensions were not implemented. Pointers were a hot topic in F90. There was a contingent who fiercely opposed the idea, as it can make automatic optimization very difficult--and it's equally difficult to see why it's necessary, as Fortran has survived for decades without them. And there were the problems that someone always had a neat hardware feature that no one else had who wanted a special language feature in the standard. The focus of FORTRAN has pretty much always been high performance numerical calculation. It can be used for other things, as can any other language, but even Wirth confessed that FORTRAN code consistently outran his Pascal on numerical problems. But the problem with any language, is that the more one adds to the language, the less comprehensible that language can become. C++ certainly has taken this route, as has Fortran. F2000 is so far removed it today, unless it was essential to my job. I know how to write C++ fairly well, but find myself relapsing to C for simple programs. Sometimes more isn't better. --Chuck

On 9/23/2015 11:17 AM, Jon Elson wrote: POSIX is not, in its origins, was not a language standard. It was an OS interface standard. Really not relevant to the discussion, I think. I do agree that trying to provide a POSIX compliant operating system interface on such a machine would be impractical. Even if you could do it, there would not be enough memory. Naturally, C programs that depended upon, say, a numerically encoded character might fail, but one could still provide functions that converted from a number to a character and vice/versa (as in PASCAL). The 1410 (which is what I originally mentioned, not a 1401) does have a floating point - normally implemented in software, but also available in hardware (standard on a 7010). I have to believe the 1401 had to have something similar, since there were FORTRANs for it. ;) The series would be more properly referred to as the 1400 series. The 1410 is not like, say, a 1440 which offers 1401 compatibility, aside instead of a 1410. JRJ

On 9/23/2015 4:27 PM, ben wrote: Yes, STAGE2 and friends pretty well faded out when LR grammars and parsers and parser generators became more widely understood and used. JRJ

On 9/23/2015 6:24 PM, Chuck Guzis wrote: Shades of SIL for SNOBOL and also STAGE2. JRJ

That depends on the compiler. I remember the PL/C compiler (from Cornell, running on IBM 370s). In graduate school, we were forced to use it because the instructor was also the main author of that compiler. It was used in a compiler construction class, with heavy use of macros. That seemed fine except for one fatal flaw in the macro engine design. PL/I has the notion of "source margins" -- source code is only processed between colums 2 and 72 (by default; those limits are settable). The fatal flaw was that the PL/C macro processor sat before the source margin machinery, so it had to obey the source margins in doing macro expansion. Unfortunately, it couldn't do that. A typical result of attempting to use a complex macro was a compiler crash. To cure it, you'd add or remove spaces from the macro call and/or the macro definition -- at which point you'd get a crash or compiler infinite loop at some other macro call. After a few weeks of that, we convinced the instructor to drop this bogus piece of software and switch to a real compiler -- Pascal on the PDP-10. paul

On 9/23/2015 1:23 AM, Chuck Guzis wrote: Because ??? (As far as that goes, just about *anything* would be ill-suited to solving numeric problems on a 1401 (or a 1410 for that matter - that wasn't a typo). The *machines* just weren't well suited for it, with or without the floating point accelerator. If you wanted that, you got a 7000 series machine).

On 9/23/2015 9:10 AM, Mouse wrote: An int just has to be able to store numbers of a certain magnitude. Same with long. You do have to be able to convert between longs (and possibly ints) and addresses (*). So, you make an int 5 digits (which matches the natural length of addresses) and longs something like 10 digits. You don't have to simulate anything, near as I can tell. Then the length of an int is 5 and a long is 10 (instead of the more typical 2 and 4). I think what you are referring to by stating anything can be copied using char-based types is (void) * - "I don't know what this points to". But using (void) to copy things will work fine, so long as they are actually compatible in length and type - which is true of most any C implementation. One interesting design decision would be whether or not to try and exploit the whole wordmark part of the architecture in native code when doing assignments or comparisons of like types, as opposed to some kind of threaded code implementation, and not bothering with wordmarks at all. A case could be made for either approach. (The PDP-11 DOS FORTRAN largely generated threaded code, BTW). And, naturally, one would have to do some kind of stack emulation. It might not be ANSI C (any more than FORTRAN II is FORTRAN IV or BDS C was ANSI C), but one could certainly come up with a decent, useful C for such a machine. JRJ

Worse yet, two's complement binary. At least nowadays. Which makes me suspect that there had to be some shortcuts taken when C was implemented on the CDC 6000 series. (Interestingly enough, if you ignore that little detail, it isn't terribly hard to write the skeleton of a 6000 code generator back-end for GCC...) paul

No, but unsigned integer types have to work as if it did. Signed integer types may use two's complement, one's complement, or even sign/magnitude, but nothing else; for example, implementing signed integers with base -2 is not permitted. 6.2.6.2 in the very late C99 draft I have, notes manually edited in: [#2] For signed integer types, the bits of the object representation shall be divided into three groups: value bits, padding bits, and the sign bit. There need not be any padding bits; there shall be exactly one sign bit. Each bit that is a value bit shall have the same value as the same bit in the object representation of the corresponding unsigned type (if there are M value bits in the signed type and N in the unsigned type, then M<=N). If the sign bit is zero, it shall not affect the resulting value. If the sign bit is one, the value shall be modified in one of the following ways: -- the corresponding value with sign bit 0 is negated (sign and magnitude); -- the sign bit has the value -(2N) (two's complement); (that's -(2^N), mangled by textification) -- the sign bit has the value -(2N-1) (one's complement). (that's -((2^N)-1), mangled by textification) Which of these applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for one's complement), is a trap representation or a normal value. In the case of sign and magnitude and one's complement, if this representation is a normal value it is called a negative zero. ... [#5] The values of any padding bits are unspecified.45) A (the "45)" is a footnote reference) valid (non-trap) object representation of a signed integer type where the sign bit is zero is a valid object representation of the corresponding unsigned type, and shall represent the same value. /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTML mouse at rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B

On 9/23/2015 11:22 PM, Eric Smith wrote: Bla Bla Bla ... What happened to seven bit ASCII? I think the major change in C from the OTHER programing languages is BYTE addressing. Even Pascal from what I have seen packs characters in words of some kind. That is main dividing line in how memory can be accessed. char *ptr++ vs array(foo-1) 0-99 can hold a trimmed character set and 10 digits per int. 5 chars per word sounds right on decimal machine. Logic operations would be on the digit rather the binary level. This may not be standard C but I has the early PDP 11 C feel if they I developed UNIX on decimal machine. Ben.

On 9/24/2015 2:04 AM, ben wrote: On a 1410 (or 1401) 0-63 can hold the entire character set using char/int conversion instead of storing chars as their native bits, and then we have 5 digits per int as the native integer size (size of an address). 0-127 would be required to hold a character with a work mark bit, which I think one would probably want to make available at a character level, but try and avoid having them set inside of ints. Also, on a 1410 or a 1401 with the right optional features, bitwise operations (bitwise &^|) could still be carried out on a binary level without undue difficulty. As you say, logic operations (&&, ||) would presumably use int 0 and 1 - but could still be carried out on a binary level. Precisely. JRJ

From: Jay Jaeger Sent: Thursday, September 24, 2015 8:01 AM [snip] Wasn't there? I realize that the 1410 was not code compatible with the 1401, but the architectures are similar enough that I would expect them to have similar compilers. I know that the 1401 had a FORTRAN IV compiler, because that was my first computer and first language, back in the spring of 1969. Rich Rich Alderson Vintage Computing Sr. Systems Engineer Living Computer Museum 2245 1st Avenue S Seattle, WA 98134 mailto:RichA at LivingComputerMuseum.org http://www.LivingComputerMuseum.org/

On 9/24/2015 2:12 PM, Rich Alderson wrote: Nope, there was no FORTRAN IV for the 1410. But yes, there was indeed one for the 1401.

On 2015-09-24 12:06 PM, Fred Cisin wrote: We don't have to reach back into the past for examples, either: Embedded processors often have unabashedly non-ANSI C compilers with "unusual" features and built-in types. One that I've used is Microchip PIC C. --Toby

On 09/22/2015 08:49 PM, Chuck Guzis wrote: Yes, quite true, BUT it also makes recursion and pointers easy to do. These are modern things that were really hard in the original FORTRAN. Jon

On 9/22/2015 10:44 PM, ben wrote: Huh?

On 9/22/2015 11:22 PM, ben wrote: What confused me is what was meant by "compled err". Say what? Huh? Anyway, I addressed in another response just how trivial it would be to define a complex number as a C "struct", and write a set of routines for the necessary manipulations (arithmetic operators, input/output/transformation from and to strings, etc). In C++ one could even overload the normal arithmetic operators for that. Not an issue at all. Indeed a definition and set of routines to do the computational part of a "complex" data type exists in the book "Numerical Recipes in C". Takes all of 3 pages. JRJ

On 9/22/2015 2:22 PM, Diane Bruce wrote: And where do get said Knowledge? Ben.

On 9/21/15 2:33 PM, Chuck Guzis wrote: Was there something before http://bitsavers.org/pdf/eth/pascal/ETH_Pascal_Listing_Nov72.pdf ? looks like 6600 assembler to me

On 2015-09-21 21:18, Fred Cisin wrote: And GOD is REAL unless declared INTEGER... Yes, FORTRAN is fun. :-) Johnny -- Johnny Billquist || "I'm on a bus || on a psychedelic trip email: bqt at softjar.se || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol