On Wed, Feb 18, 2015 at 8:34 PM, ben <bfranchuk at jetnet.ab.ca> wrote: Yes, there is at least one 1401 that is routinely up and running, at CHM.

On 02/18/2015 07:56 PM, William Donzelli wrote: The point is that COBOL, FORTRAN, Algol, etc. get a bad rap. Look what they had to run on--you can't do that with C or several other more contemporary languages. Which brings up the question "Do you design a machine to run a language or design a language to run on a machine?" That appears to have changed over the last 30-40 years. Are we poorer for that? The financial world didn't seem to mind decimal machines. Are we going to make a dollar (or Euro) equal to 128 cents to accommodate radix-2 machines? --Chuck

On Wed, Feb 18, 2015 at 11:21:10PM -0800, Chuck Guzis wrote: C will run on all sorts of bizarre machines, but somebody has to bother to implement it, and if the architecture is weird enough that the language has to be contorted in unexpected ways, it will break assumptions made in typical C code. ISTR that current versions of the standard assume a binary machine that provides particular word width, but earlier versions give much more flexibility. That modern compilers don't support obsolete machines isn't a surprise. I can't find a decent modern C compiler that targets m68k, for example, even though that architecture is still just about clinging on to life. Modern CPU architectures all appear to have been designed to run C or languages with much the same memory model. This seems so ingrained that it doesn't appear to occur to software developers that there are other potential schemes. This is a great loss on both fronts. You can do decimal and fixed-point arithmetic on contemporary binary machines just fine, but there's just no hardware acceleration[0][1]. Or just go full gonzo and use floats and hope that the rounding errors don't become significant, which is sadly all too common. [0] Although I note that divide-by-constant is most typically implemented by modern compilers as a fixed-point multiply-by-reciprocal. [1] x86-64 doesn't support BCD in long mode and repurposes the opcodes. This is no great loss given how half-arsed x86's BCD support was.

clang already does that, even for perfectly well defined constructs that the clang folks got outlawed in the standards process. :( Warner

On Thu, Feb 19, 2015 at 10:11:32AM -0800, Chuck Guzis wrote: I have no particular interest in the IBM 1620, so don't plan to spend any effort on finding or creating a C compiler for it. The 7000-series is obsolete because it consists of several incompatible architectures, splitting the software market, and then IBM rendered it obsolete anyway with S/360. There's probably also something odd about the design that made it unsuited for high-level languages, but I can't quickly find a good description of its ISA and don't feel like downloading half of Bitsavers. It's bloody awful for all of them :) If I have to write C at all, I prefer to write the useful subset of C++ so I can get better type abstraction. C++11 has "strongly typed enums" which are handy but also slightly half-jobbed in their design and can be infuriating to use. This makes them fit in just fine with the rest of C++. C does support bitfields, but can't take the address of one. The latter is a fairly uncommon requirement though, and so algorithms that require it will have to roll their own using mask and shift operations. Given that x86 doesn't have bitfield instructions and has to fake it with mask and shift, this is no great loss in practice. It wouldn't surprise me if there was a bitfield_ptr<> in Boost which did this.

The frustrating thing for me is not just the instructions but the memory model. Some of the issues (security springs to mind) that we're facing today can be solved by *not* having a completely flat memory model. I'm still a fan of tagged memory. ;-) TTFN - Guy

On 02/27/2015 01:23 PM, Roe Peterson wrote: Again, it depends on the implementation. I never noticed that APL was particularly slow on a STAR-100, but then, that architecture suited the language. APL certainly encouraged thinking about things in a different way. I wonder what today would look like if APL was used as a "first language" to teach programming. --Chuck

On Fri, Feb 27, 2015 at 04:48:07PM -0800, Chuck Guzis wrote: [...] It's a special-purpose language for mathematical manipulation. As such, it's not actually a very good choice for a first language. When I was a wee nipper, everybody's first language was BASIC because that's what came with the machine. These days, it's more likely to be Java or perhaps Python. Python's the better of the two and supports similar manipulations to APL. For example, Python forms of the examples in https://en.wikipedia.org/wiki/APL_%28programming_language%29#Design are: [4, 5, 6, 7] [8, 9, 10, 11] 22 22 And in Scala, which runs on the JVM and thus interoperates with Java: scala> val n = Vector(4, 5, 6, 7) n: scala.collection.immutable.Vector[Int] = Vector(4, 5, 6, 7) scala> n res0: scala.collection.immutable.Vector[Int] = Vector(4, 5, 6, 7) scala> n map (_+3) res1: scala.collection.immutable.Vector[Int] = Vector(7, 8, 9, 10) scala> n.sum res2: Int = 22 scala> val m = 1 to 4 map (_ + 3) sum; m warning: there was one feature warning; re-run with -feature for details m: Int = 22 res3: Int = 22 The "feature warning" is that I used postfix "sum", which is an ambiguous parse in some cases. It wants me to write it as the uglier (1 to 4).map(_ + 3).sum Functional programming idioms have crept into many OO and imperative languages to give them APL-like power. APL's cryptic syntax is not a feature; if you want that, you know where to find Perl or Clojure.

On Sat, Feb 28, 2015 at 09:19:54AM -0800, Robert Ferguson wrote: Oh, alright then :) I have skimmed quite a lot of it as it's quite long and I don't actually care to learn APL, but it has a few central points that fit in a few pages, with 50 pages of exposition: a) Mathematical notation is inconsistent and the meaning varies depending on topic; b) "Most programming languages are decidedly inferior to mathematical notation"; c) It is possible to unify the two, this is actually desirable, and APL delivers; d) Similar problems should have similar solutions, and language features should be orthogonal and composable in obvious ways; and e) Brevity is of the essence. It is of particular note that this lecture was given way back in 1979, a time closer to the invention of the computer than the present day. It is thus (rightly) criticising the state of the art in the early days of computers. The state of the art has moved on somewhat since, even if most modern-day programmers still seem to be stuck in the BASIC mindset. Point a) is trivially supported: Newton and Leibnitz invented different notation for calculus, for example. b) is utterly subjective with no evidence presented and is clearly a case of [citation needed]. The author evidently believes that programming languages are decidedly inferior for mathematics which is very much a case of "well, duh, that's not what they're designed for!" c) is getting into the meat of it. Where the author says "mathematical notation", what is really meant is the subset of said notation which describes arithmetical expressions, and thus which can be computed by rote. Similarly, expressions are a subset of programming languages. It follows that where mathematics and programming intersect, one can use the same notation. It is certainly the case that expressions in many programming languages do resemble mathematics: 1 + 2 means the same in both, * is used for multiplication without incident, and the operations have the same rules for associativity, distributivity, and so on. It is also the case that this is a desirable trait since it reduces the learning curve when approaching a new discipline. APL itself uses + and * to denote addition and multiplication, but then wanders off in its own direction, no doubt much to the bemusement of mathematicians and programmers alike. APL fails as a programming language because it is quite unlike more familiar programming languages, and doesn't offer anything new. It may have been novel in 1979 but I doubt it was even then. It requires special support from the environment due to its non-ASCII character set, adding further friction. APL fails as a mathematical notation because it is quite unlike more familiar mathematical notation, and doesn't offer anything new. Indeed, it seems to fall short in that it only concerns itself with arithmetical expressions and not mathematics as a whole. It's very much like Esperanto. The British and the French don't bother to learn Esperanto because it's too much work for too little gain, so we just pick up what we need of each other's language, and all is well. d) is another case of "well, duh!", and is hardly unique to APL. And Lisp predates APL by six years... We finally get to e). The dense APL examples very much supports my opinion that the language is unnecessarily obtuse. However, I'll dig out a more contemporary example: Some programming languages (C++, Perl, Python, etc) allow operator overloading, i.e. that they allow programmers to define functions for user-defined types which mimic arithmetical operators. For example, one could overload * to perform matrix multiplication. Some go even further (Scala, PostgreSQL) and allow more arbitrary sequences of characters as operators and not just those combinations that are in the base language. And others (Java) just forbid it as a bad idea. When given operator overloading, library designers go hog wild and invent Domain Specific Languages (DSLs) which contort the language by eliminating parentheses, adding no-op noise words to make it more English-like, and various other abuses that are somewhat against the spirit of the language. This results in very pretty-looking portfolio examples for the project's github page, but also an API that turns out to be somewhat brittle and error-prone as the human author and the compiler have different ideas of what is valid code and what it means. Whenever I encounter this sort of thing, I start to think that Java's designers may have been onto something after all. Two important traits of programming languages is that it be easy to describe an algorithm to a computer without lots of trial-and-error, and that the program be readable understandable by other people (or the original author months later when they've forgotten what they did) and the meaning obvious. APL fails spectacularly on both points. So do a lot of languages popular today, but that doesn't forgive APL for actually believing this to be a desirable trait.

On Feb 28, 2015, at 11:46 AM, Peter Corlett <abuse at cabal.org.uk> wrote: Well done. I look forward to your thoughtful and modest critiques of other Turing award winners life's work.

To my mind that is why it _succeeds_ as a programming language. Perhaps I'm just revealing the paucity of the languages I know, but it does to me - in particular, it's one of the very few languages I know in which arrays are first-class objects, and the only one I know with a reasonably rich set of operators tuned for operating on arrays. It doesn't, actually; I've seen APL systems described which use ASCII substitutes for the various `special' characters. (I suspect code written that way would be less readable than with the proper characters, but that's equally true of, say, C's trigraphs.) It is. But I'd say that's a positive thing; a language that isn't an interesting toy - ie, isn't fun to play with - is unlikely to be much good for anything larger. /~\ 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 Mar 3, 2015, at 4:00 PM, Mouse <mouse at Rodents-Montreal.ORG> wrote: Mouse, one other, which you may or may not classify as a ?language?, is Mathematica. I hesitate a little to recommend it, because for most of its history, the price of entry has been pretty high, but at the moment it?s a free download for Raspbian on Raspberry Pi, which puts it in the $50 US or so range, depending on what cables, power supplies, etc. you need to buy and assuming you already have monitor, KB, and mouse and can supply ethernet connection. I do recognize also that the language has a pretty steep learning curve. This is a reasonable description of the language and its place within programming styles. http://www.mathprogramming-intro.org/book/node66.html As you can maybe guess, I?m a fan and user, but not otherwise connected. - Mark

I've been using Mathematica for years. It's an extremely powerful tool. I especially like the whole notion of notebooks. I've also used MatLab which also falls somewhat into that category. MatLab is is really optimized around vectors and arrays. A somewhat similar tool is Maxima (a clone of Macsyma) that is derived from the original at MIT and work continued by DOE. I've never been rabid about closed vs open source. If there's a good tool that runs in an environment I use/have access to, I use it. I don't have the time to mess around with trying to get tools to work. After more than a decade of working on Linux (both personally and professionally) I finally gave up due to incompatibilities and getting into circular loops and the weeks spent trying to get a system configured that would run various tools (without having to have a different system for each tool). I had several cases where one program needed a specific version of a system library, another program needed a *different* specific version of the library and the rest of the system wanting yet a 3rd version of the same library. TTFN - Guy

That might be more similar to APL, then. This has been rattling around in my mind for a little while now and I think one reason I didn't think of things like Mathematica or Matlab is that they're single-implementation. Most of the things normally thought of as programming languages are more or less independent of their implementations, with multiple independent implementations. Things like Mathematica, while they certainly can be seen as languages, have only one implementation, often have an imprecise (or no!) spec beyond "what the implementation does", and sometimes even come from vendors who think they own the language somehow, throwing around lawyers if anyone else tries to create an independent implementation. (I don't know which, if either, of those applies to Mathematica specifically, but I _have_ seen examples of each.) This makes them less useful; for example, even if I were willing to run someone else's binary, I doubt Mathematica exists for NetBSD/sparc 1.4T. /~\ 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 06/03/15 9:40 AM, Mouse wrote: It certainly existed on SPARC, though... Mathematica was very widely ported because of the era it was born in - it supported just about every serious platform of the 1980s - I remember seeing price lists with maybe 50 different ports, everything from SPARC to Mac to Cray (at the time I used it on Mac 68K and I have a license for NeXT). Wolfram's pathologically proprietorial mentality doesn't support the spirit of openness that progress and science require; a tragedy when so many have sleepwalked into relying on his black-box tools ... --Toby

On 3/8/15 9:43 AM, Guy Sotomayor wrote: One of the things that I really appreciate with both Mathmatica and MatLab is the fact that they can handle enormous data sets that other tools choke on. At a previous employer, I justified the expense of Mathmatica because I had to do some analysis on some trace files that had on the order of 100,000,000 records. I had previous experience with smaller files and using Excel spreadsheets that indicated spreadsheets were just not up to the task. Once I had coded up what I needed in Mathmatica's language, I could do the processing/analysis of the trace files in about an hour. Even with much smaller data sets, spreadsheets (Excel specifically) took significantly longer. The way I had coded in Mathmatica was probably not the most efficient. Just like proper APL, there were no loops in the code. The entire trace file was read into a list and then applications of "map" were done on the entire list (sometimes doing a selection from the list). One of the powerful features is applying a test against the list and getting a bit vector out (one bit per list element) for the entire list (a really long bit vector). You could then use the bit vector directly (I had used it for some frequency analysis) or to extract a sublist for different processing. TTFN - Guy

I thought it was a PDP-7 minicomputer? (Or is that Unix?) But while C was first run on a DEC minicomputer, it isn?t in any significant way ?for? those computers, any more than Fortran or COBOL are for IBM computers. All high level languages are pretty portable, some a bit more so than others. For example, Fortran fits comfortably on CDC 6000 machines (60 bits one?s complement) and IBM 1620 (decimal variable length); C doesn?t. If you really stand on your head, you can sort of make it work; there exists a C for the 6600, for example. But you have to stretch, if not outright violate, a number of the language rules to do so. I think the limitations and design of C come from the fact that it was designed for OS implementation, not high level application implementation, as APL or various other languages were. Compare C with Bliss and Sympl and ESPOL, not with APL or Snobol. Given that focus, it?s pretty good. Certainly better than Bliss. The other two suffer from being implemented only on single proprietary platforms that have long since disappeared, and Sympl didn?t have much going for it anyway (being based on Jovial is certainly a recipe for disaster). It would have been nice if ESPOL had evolved to be a portable language as C was, but that didn?t happen. C does have extensions for vectors; I know GCC does, and for all I know those may be standard rather than GCC specials. I suppose there?s always Ada if you want a clean portable systems programming language... paul

On Fri, Feb 27, 2015 at 1:01 PM, Chuck Guzis <cclist at sydex.com> wrote: But evolved from B, which was on the PDP-7, and which had many of the language features people have falsely blamed on the PDP-11, such as the increment and decrement operators.

On Fri, Feb 27, 2015 at 11:27 AM, Chuck Guzis <cclist at sydex.com> wrote: Developed for the PDP-7, actually. Contrary to popular belief, the "++" and "--" operators were NOT the result of the PDP-11 addressing modes.

On 02/27/2015 11:52 AM, Eric Smith wrote: Also, this from DR: http://cm.bell-labs.com/who/dmr/chist.html While there was B for the PDP-7, was there ever a C for it? --Chuck

On 02/27/2015 01:18 PM, Johnny Billquist wrote: Although ++ and -- were convenient for code writers, they did lead to some "it depends" implementation details WRT function calls. I assume that ANSI C has straightened that all out, but I still avoid that type of thing by habit. Digressing a bit, I recall talking with a fellow from Xerox on Coyote Hill Rd. (not Xerox PARC) back in the early 80s and being surprised that he said they coded in B. Was this the same B developed on the PDP-7? Or was it some other beast? --Chuck

On 02/27/2015 02:03 PM, Johnny Billquist wrote: Yes, and that's just it--it's an operator with an implied LHS, that is, it not only returns a value, but alters its argument. In languages preceding it, I'm not aware of such an operator. But was the "B" used by Xerox in the 80s, the same language? --Chuck

On 02/28/2015 04:59 AM, Johnny Billquist wrote: I looked up the instruction set of the PDP-7, ghastly little machine, basically a PDP-8 extended to 18 bits. Stored the return address in the first word of the subroutine, just one accumulator, conditionals were done with a skip instruction, so you did this skip / jump structure for conditional branches, unless the conditional code was only one instruction. All the stuff I disliked on the PDP-8. One oddity was there was a 13-bit address field in the instruction, but it was possible to have more than 8K words of memory on the machine. Another oddity is there were both ones-complement and twos-complement add instructions. I guess the designer just couldn't decide which arithmetic representation to use? Jon

On 03/01/2015 05:42 AM, Johnny Billquist wrote: Yeah, SOMETIMES. But, a conditional branch ended up always being two instructions. I did a bit of work on the LINC, which was ones complement. The messy bit was that if you compared negative zero against positive zero, you got a not-equal indication. So, you needed two compare strategies to be sure to know that -0 really did equal +0. UGLY! Of course, it would have cost a bunch of gates to fix that glitch. Jon

On 03/01/2015 11:36 AM, Johnny Billquist wrote: I don't know--I'm of mixed feelings about it. I've been on both sides. If -0 and +0 both tested as zero, that was fine in most cases. Worst case, you added +0 to the value in question, which would have the effect of converting -0 to +0. Ones complement has the curious benefit that some bit-twiddling operations can be very useful and not possible otherwise in two's complement. See: http://www.fourmilab.ch/documents/univac/cute_tricks.html for similar tracks on the Univac 1100 series. What I've developed a definite distaste for is condition codes on machines with significant register files. I can understand their application in memory-to-memory architectures, but on register or register-memory, they make little sense and get in the way, particularly when scheduling instructions. For me, that's one of the biggest drawbacks of the x86 architecture. --Chuck

On 3/1/15 3:42 AM, Johnny Billquist wrote: It makes sense on machines with a single word order code. Incr instruction pointer by one and you're done. It makes much less sense on multi-word order codes where you have to crack the instruction to see how far to advance the instruction pointer.

On 2015-03-01 22:39, Jon Elson wrote: I don't think so. On the PDP-8 at least, the increment of the PC is done at different clock phases for different reasons, and they are not combined. I/O peripherals can also increment the PC, and it happens at a defined time. The clock state machine of the PDP-8 is somewhat complex compared to more "modern" machines. 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

On 2015-03-01 23:03, ben wrote: Uh... No. The timing in the PDP-8 is very specific to the PDP-8. A cycle contains four states. Different operations in the CPU instruction execution happens at different states. The length of each state is specific to that state. Admittedly, states in which memory is accesses were defined based on the speed of core memory, but that is just a small part of the picture. Some states only exists for certain instructions. Indirect dereferenceing only happens if the instruction has the indirect bit set, and the DMA state only happens if there is a DMA request active (or Data Break as it was called). The whole time state machine is built based on how the PDP-8 instructions work. It's far from as generic like you suggest. Yes. :-) 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

On Sun, Mar 01, 2015 at 09:59:12AM -0800, Al Kossow wrote: OK, true story time. Those who have been around computing for a while will be able to put a pretty close range on my age with this one. My _second_ computer was a PDP-8. Remote timeshared. IIRC an 8/M. I _do_ remember what happened when the 4th user logged in: (nothing) It was usable with 1 or 2 users. But my confusion was the assembler manual. I looked at the example listings and thought "but how does it know in what order to execute the instructions?" You see ... my *first* machine was a Bendix (although late enough to be labeled Control Data) G-15. Those have drum memories. 29-bit words, too. And, due to rotatinal latency, the address of the next instruction is _contained_ in each instruction. You can imagine the games that were played to optimize (and, in a few specific use-cases, pessimize) access time over an instruction stream. I think it took me a good 30 minutes to puzzle out "oh, I guess they just use the next instruction in the sequence." (Yes, I already understood test-and-branch operations. I mean, other than that.) mcl

On Sun, Mar 01, 2015 at 09:51:25PM -0600, Jon Elson wrote: Too bad. Was it physically dead, or just the bits scrambled? IIUC there was _one_ machine that was set up to write the timing track. It was at the factory :-) When was this? What happened to the pieces? mcl

On 01/03/15 6:42 AM, Johnny Billquist wrote: Studying the CDC 6000 instruction set (through the Grishman book) really gives me the impression one's complement would be quite a headache to use correctly. --Toby

On 03/01/2015 04:08 PM, Al Kossow wrote: Again, it depends. On the CDC 6000 series, integers for doing math were pretty much 48 bit as multiply and divide were done using the floating point unit. The long add unit did 60 bit integer adds and subtracts. So, if you kept to 48 and 96 bit integers, it was no worse than on any other machine. Even extended precision integer math on the PPUs was less of a hassle than you'd think--the memory word length was 12 bits, but the accumulator (A) register was 18 bits long. Seymour Cray was no fool. --Chuck

On Mar 1, 2015, at 4:48 PM, steve shumaker wrote: That is odd, I have been receiving email from other folks. Thanks for the ping, I will phone this afternoon. ok bear. -- until further notice

It isn?t, actually. One?s complement has some handy properties; a number of arithmetic operations that are distinct from common logical operations in two?s complement share those operations in one?s complement. For example, you don?t need a separate negate and complement; one operation serves both. One critical bit of design is that the ALU needs to be a subtractor rather than an adder, otherwise you end up with -0 as the default zero result. It?s interesting that CDC extended the one?s complement approach to the float format, unlike the (at least nowadays) conventional approach of sign/magnitude encoding. And with the binary point at the right rather than left of the mantissa, you end up with integers (up to 47 bits) being valid floating point encodings of that same value. paul

Its history is deeper than that. Its part of a family of bracketed languages that started with BCPL which became "B" and then "C". BCPL was written for the IBM7090. Dave G4UGM

I don't think we are in total disagreement. I also thought it was written at Cambridge for Atlas but the the Wiki page:- http://en.wikipedia.org/wiki/BCPL says the first implementation was when Martin was working at MIT for the 7090. As WIKIs can be wrong, I googled around a bit, and that turned up the MIT TX-2 BCPL manual at BITSAVERS :- http://www.bitsavers.org/pdf/mit/tx-2/TX-2_BCPL_Reference_Manual_May69.pdf which says that in 1969 it was running on Project MAC but not yet on the Atlas, and also on the GE635 which later became the Honeywell 6000 and Level 66 series, on which I had my first baptism of fire with structured languages, being introduced to "B". I also think this was the same "B" that ran on Xerox kit, as I believe they were also used at MIT... <<<extract from TX-2 BCPL manual>>>> 1 .0 Introduction ============= BCPL is a general purpose recursive programming language which is particularly suitable for large non-numerical problems in which machine independence is an important factor. It was originally designed as a vehicle for compiler construction and has, so far, been used in three compilers. BCPL is currently implemented and running on eTSS at Project MAC, the GE 635 under GE COS and on a KDF 9 at Oxford. Other implementations are under construction for MULTICS, the ICT 1900 series I Atlas I the System 360, and the TX-2. The language was originally developed and implemented by M. Richards at Project MAC. <<<end of extract from TX-2 BCPL manual>>>> Dave Wade G4UGM

On Feb 28, 2015, at 1:40 AM, Dave G4UGM <dave.g4ugm at gmail.com> wrote: Thinkage.ca will happily sell you one for GCOS. It is excellent in many respects. http://www.thinkage.ca/english/gcos/product-uwtools.shtml

On 2015-02-28 00:19, Dave G4UGM wrote: And here I was sitting, thinking they all originated with Algol... 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

On 28/02/15 9:01 AM, Paul Koning wrote: language, and most block structured languages since then copied its approach to name and data scope. (Not all; for example, Python has scope rules that are noticeably different.) Python's lexical blocks follow the "offside rule" (as do Haskell's). This rule was originally described by Peter Landin in his 1966 paper "The Next 700 Programming Languages". (Wikipedia has more on ISWIM and the offside rule.) --Toby