Liam Proven wrote on Fri, 29 May 2020 14:20:53 +0200 The modern variation of the Turing Tarpit. At least they come to this illusion honestly given that you even have people who think implementing Forth in C is the way to go. Of course, given that NAND2Tetris teaches them that everything is built that since a microcoded processor has a little Harvard machine inside it can't do stuff that this architecture can't (like self modifying code). Sometimes the way to gain something is to take away possibilities rather than add them. This is not intuitive at all, but it is what levels of abstraction are all about. Back to the subject, it would be funny to see their reaction to the sources for GWBASIC and the fact that it was NOT written in C. -- Jecel

On 5/29/2020 12:42 PM, John Foust via cctalk wrote: Is C portable because most the machines the same kind,8/16/32 bits with greater than 512kb ram? or that C runs on more kinds machines? Or is C portable because of unix? BTW Microsoft also had Fortan, You don't hear much about that. Ben.

Yes. But the same is true for many languages. Fortran is a particularly good example, but there are plenty of portable languages (Algol, Basic, LISP, Python, COBOL, Ada, RPG, ...). Some more than C; for example, C doesn't like one's complement machines (though it has been ported to at least one) and things get somewhat interesting if the machine doesn't have byte addressing. Since C aims to be a system implementation language, unlike Fortran or Basic or Algol, it tends to expose, or at least let you see, machine details. That can get in the way of portability. One small example is that C thinks address 0 is a null pointer rather than a valid pointer. On modern systems that is true (partly because C says so) but on a PDP-11 it isn't. paul

On 5/29/20 5:24 PM, Jim Brain via cctalk wrote: PL/M? bill

On Fri, 29 May 2020, Dave Wade via cctalk wrote: And before B was BCPL. BCPL was used to Bootstrap B was used to Bootstrap C. BCPL equally rapidly lets you shoot yourself in the foot.. It's fun though. I'm in the middle of creating a lttle retro project and I'm using BCPL as its "self-hosting" programming language. Gordon

True. "High level assembly language" is one tag applied to C. It also means it has weaker safety properties than most high level languages. Being "feebly typed" is one example. There are certainly other, lesser known, languages that have similar properties. FORTH is one. Two that are not inherently machine-specific but were only found on one architecture are ESPOL (Burroughs mainframes) and SYMPL and CYBIL (CDC 6000 series mainframes). And of course BLISS, on a number of DEC machines. paul

On 5/29/20 3:41 PM, Fred Cisin via cctalk wrote: Yes, a pointer to the PC Interrupt Vector Table could be problematic. Oh, FORTRAN can do likewise--I suspect that most languages can be coaxed (perhaps with some assembly-language subroutines)to do something nasty. Two cases in point (but I have lots more). In the CDC 60-bit machines, one of the most useful functions was LOC(). It passes the address of the argument. Note that this was basically a single instruction as FORTRAN uses call-by-reference in most older versions. The other aspect of the CDC operating systems is that PPMTR looked periodically at each user's location 1 for system requests. So, it was a simple matter to use LOC() to obtain a negative subscript into an array to write and read that location. With the ability to make system requests directly (and directly address user memory), the sky is the limit. Indeed several user-written system utilities were written using just that technique. The CDC iron is word-addressable only. (Other abuses were the arbitrary target for the ASSIGNed GOTO, but that's another subject). Similarly, BASIC, depending on the version, could be abused. One technique was to use a character array with the BASED attribute (I don't know if I was the first to invent that keyword, but it was around 1978). That turned the variable into a pointer and one could change the area that the variable pointed to with the BASE...AT statement. Several utilities were written in this fashion, including a few that located the video refresh buffer and wrote to it directly. I've been known to do similar nasty things in COBOL. Side question: How does one create named COMMON in C? --Chuck

Chuck, your post just reminded me of how I used FORTRAN to interface with my PDP-11 ASM routines when I was doing data acquisition as fast as possible on a MINC system. Perused my FORTRAN code about 6 months ago and had common blocks and a routine which took "arrays" which were essential chunks of PDP-11 memory that I'd use as data buffers and to access data in my ASM routines directly. Certainly a lot faster than doing function calls to get at this data but would now be looked at as very "dangerous" programming. Considering I was limited to <56 Kb of RAM for all my code and data I used a very stripped down version of RT-11 and found it simpler to create a RAMdisk out of the high memory on the 512 Kb memory card and wrote a VM driver to stash A/D data there. For this type of programming one needs to look at scalability properties of a system. That 11/23 system looks like a toy now compared to a cheap FitBit but the MINC had one job to do and needed to be pushed to its limits to do it. I documented my code well (or so I thought) but after 30+ years it took me a while to figure out what I was doing. For a dedicated system, code like that is necessary if one doesn't have the option of getting a more powerfull machine that can provide the necessary data acquisition speed as well as allowing "safe" but much slower code given the need to perform frequent checks on variables, address bounds, etc. One needs a machine that can operate in supervisor and user modes with supervisor memory protected but each context switch takes time. Used to be able to do this sort of stuff with early Windoze but everything tightly sandboxed now. Now, if I want to do any reasonable speed data acquisition have to build a microprocessor system which is fun to code and then connect it via USB to a Windoze "mainframe" for analysis. Of course, if one really wants speed, then one can use Ciarcia's "solder" programming language. Boris Gimbarzevsky

On Fri, 29 May 2020, Chuck Guzis via cctalk wrote: "A real programmer can write a FORTRAN program in any language." But, a REAL programmer, such as Chuck, can write any language program in FORTRAN. "A computer without FORTRAN or COBOL is like a piece of chocolate cake without ketchup or mustard." In addition to GWBASIC, don't forget BASCOM, the Microsoft BASIC compiler. It's top two uses were 1) a small speed improvement 2) marketing a program written in BASIC without revealing the source code. Overheard at Comdex: "What language is it written in?" "I'm not at liberty to discuss that." "OK, WHICH BASIC compiler did you use?"

Most languages will give you some way to shoot yourself in the foot. The question is how much work do you need to do? In FORTRAN the easiest method was changing the value of a literal in a subroutine call. It is standard compliant behavior that goes back to at least FORTRAN IV. Current compliers and converters go to pains to make sure it still happens. Not sure if it is still present in f90 and beyond. At least modern compilers for other languages will give you a "potential foot shooting warning", although in C++ that warning statement could take 200 kB. C C CHANGE THE VALUE OF 4 C CALL INC(4) WRITE (*, 30) 4 30 FORMAT ('2+2=',I4) END SUBROUTINE INC(I) I = I + 1 END -------- OUTPUT 2+2= 5

On 5/31/20 3:13 PM, Eric Korpela via cctalk wrote: One of the reasons that the F90 standards people got very strict about vendor "features" (must not be allowed as the default) was that they were often added as a "good idea" without a lot of thought. I recall one from the CDC 6000 FORTRAN IV extended product that got everyone thinking. Instead of counting the number of characters in a hollerith constant as used in a FORMAT, some clever boots decided that "Hdxxxxxd", where xxxxx is the character string and d is any printable character that forms a delimiter would be a really neat feature. Thus, H*HELLO* has exactly the same meaning as 5HHELLO when used in a FORMAT statement. One day a PSR rolled in with the following question: Given the program segment shown below, what does it do? DIMENSION FORMAT(10) INTEGER HX, X HX = 1 X = 2 100 FORMAT(HX)=(-X) Observe that FORTRAN has no reserved words (that changed in F90) and spaces are ignored unless part of a hollerith constant. Well, it might be an assignment to an element of the array FORMAT--or, it might be a FORMAT statement for an I/O operation (FORTRAN does not disallow unreferenced FORMAT statements). Clearly, if there were an I/O statement (e.g. READ or WRITE) referencing label 100, the meaning was obvious. Otherwise, meh. There was no way to "fix" the problem other than to say "Don't be silly". --Chuck

Yes, and on some machines, like the IBM 1800, small numeric constants are stored in a common location, to reduce the size of executable images. So, once you've changed 4 to 5, it means that all programs that get loaded will now use 5 when they meant 4. Usually the generated code has a way to refer to zero without using the common constant area, but not numbers like 1 or 2, so setting 1 or 2 to zero will have 'interesting' effects. Especially if the machine is controlling heavy equipment. [I bear witness to the result - been there, did that...] From: "cctalk" <cctalk at classiccmp.org> To: "cctalk" <cctalk at classiccmp.org> Sent: Monday, June 1, 2020 11:40:10 PM Subject: Re: Microsoft open sources GWBASIC On Mon, 1 Jun 2020 at 00:14, Eric Korpela via cctalk <cctalk at classiccmp.org> wrote: I had no idea, and I wrote a lot of FORTRAN for a few years. I just tested the above with the Fortran-77 compiler for my ND-100 mini, and yes, it prints 2+2= 5

On Thu, 11 Jun 2020, Maciej W. Rozycki wrote: So the response from GCC Fortran experts is as follows: "[...] Yes, old compiler did dumb things, because it was/is difficult to detect this violation of the Fortran standards. Note, these prohibitions are on the programmer. "F66 8.4.2 "If an actual argument corresponds to a dummy argument that is defined or redefined in the referenced subprogram, the actual argument must be a variable name, an array element name, or an array name. "F77 15.9.2 "Actual arguments may be constants, symbolic names of constants, function references, expressions involving operators, and expressions enclosed in parentheses if and only if the associated dummy argument is a variable that is not defined during execution of the referenced external procedure." My conclusion has therefore been that this must have been a peculiarity of individual compiler implementations, in particular because numerous computer systems do not support memory protection and have no way to mark a segment read-only, and may otherwise either not support instrumentation at all or it can be disabled for performance reasons. Some implementers may have indeed gone to great lengths to support this peculiarity to keep software running that has been written for computer systems affected by this limitation, but by no means it appears standard in terms of the language definition. FWIW, Maciej

On Fri, 29 May 2020, ben via cctalk wrote: One reaason why you don't hear much about that is because the first version of Microsoft Fortran for the PC wasn't real great. It was slow. A Sieve Of Erastothanes benchmark compiled in it ran slower than in interpreted BASICA (GWBASIC with access to the BASIC ROMs in the 5150) It was written in Microsoft Pascal. (Bob Wallace, who wrote the Microsoft Pascal, once told me to never use the run-time library of it) Although I used it for teaching beginning Fortran for a few semesters, in the mid 1980s, I don't remember much about it. ("Don't use any 6 character variable names ending in QQ." doesn't help the discussion much)

On Sat, 30 May 2020, John Foust via cctalk wrote: unrelated product, with no apparent connections, that I'm aware of. The 8080/Z80 FORTRAN-80 would have been a better starting point! Bob Wallace wrote the original Microsoft Pascal; I don't know who wrote the Fortran, other than being told that it was written in Microsoft Pascal, and to avoid the run-time library. In late 1978, Microsoft also announced a version of FORTRAN-80 for TRS80. OB_anecdeote: I ordered 3 copies, for resale, through Lifeboat (Shrewsbury NJ major distributor of CP/M, DR, and MS products). For months, I got, "Oh, it was delayed, but your order just got shipped!". (in spite of telling me each previous week that it had already just been shipped.) In late February 1979, I drove with some friends from Berkeley to Lewistown Montana for the solar eclipse, but had to fly back due to work schedule. Flew back by way of Seattle. Had my friend Bob Wallace (who worked for Microsoft) meet me at the airport during my layover; he brought me three copies at the airport. (Serial #1,2,3, or maybe it was 10001, etc.) I delivered copies to the community college district, where I was teaching part-time, just in time for the start of their class. They contacted me a couple of days later; the instructor typed in the first demo program in the manual, and it SYNTAX ERROR'd out. "The compiler doesn't work." I pointed out a missing comma in the listing of the sample program in the manual, and that fixed it. "Well, it's no good if even the manual has errors." That was pretty much my only/last contact with FORTRAN-80 In Fall 1983, that instructor managed to get hired at Cal State Hayward. I got a call from the department chair, Wil Price, whom I knew well, at 6 PM, "Can you teach Fortran?" "I think so." "Great. You start tomorrow morning at 8:00 AM in room D252. Park in the visitor lot, and see me after class for a parking permit." Another call at about 8:30, "Can you handle more than one section?" "Yes" "OK, we'll have to 'LTS' ('long term sub') you to be 'full-time' immediately." When they held formal hiring for the full-time tenure-track position, a year later, I got it. Eventually tenure, etc. Over the next decade, I created additional courses. C, Microcomputer Disk Operating Systems (CP/M,TRSDOS,AppleDOs, but mostly MS-DOS), Microcomputer (8088) Assembly Language, Desktop Publishing, Data Structures And Algorithms, Introduction To The Internet, etc. The PC Fortran, written by Microsoft and distributed by IBM was an unrelated product. I think that it might be: https://winworldpc.com/product/ibm-fortran-compiler/100 We used the PC Fortran on a couple dozen 5150s in the school lab. It worked quite well for teaching beginners; I would not have wanted to use it for anything real-world. I heard that a few years later, it was rewritten, and MUCH better, so my gripes about it aren't valid for the later products. -- Grumpy Ol' Fred cisin at xenosoft.com

On Sun, 31 May 2020, Eric Smith wrote: Exactly. Microsoft Fortran for the PC, written in Pascal, was not related to Microsoft FORTRAN-80 for CP/M, which was written in 8080 assembly. Microsoft Fortran for the PC was not related to Microsoft FORTRAN-80 for TRS80, which was a derivative of Microsoft FORTRAN-80 for CP/M, which was written in 8080 assembly. Because the TRS80 was Z80, I would not be surprised if some of the TRS80 specific code in Microsoft FORTRAN-80 for TRS80 might have used some Z80. Microsoft Fortran for the PC was written in Pascal. It was an unrelated product. I don't think that any of the Microsoft Fortran products were related to the Intel FORTRAN-80. Did Microsoft ever develop anything in PL/M? Did Microsoft ever develop anything for ISIS-II?

On 5/31/20 2:24 AM, Eric Smith via cctalk wrote: Which is even funnier when you realize that the PL/M compiler was written in Fortran. bill

On 5/31/20 8:35 PM, Mich.com wrote: You are definitely right on that. I forget what it was intended to run on, probably some minicomputer like a DEC System-10 or -20. Hmmm... I wonder if it would compile with Fortran-80 on my TRS-80. That might be fun to see. I even have corrected sources around here somewhere because after all those years of people using it I found a few bugs in the two sets of sources that were floating around the Internet. :-) bill

On Sun, May 31, 2020 at 5:50 PM Bill Gunshannon via cctalk < cctalk at classiccmp.org> wrote: In at least the more recent versions, Intel FORTRAN-80 on ISIS-II was compiled with the ISIS-II PL/M compiler, which was itself written in PL/M. The ISIS-II PL/M compiler was bootstrapped from the PL/M cross-compiler that was written in FORTRAN, and it's entirely possible that early versions of Intel FORTRAN-80 were developed that way as well.

On 2020-05-29 8:20 AM, Liam Proven via cctalk wrote: You understand that this is absolute rubbish, right?