![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
Earlier drafts referred to the 16thbit being used for indirect addressing. That is incorrect. The indirect bit is in the instruction format, not the address. Addressing was 15bits (32K 16bit WORDS), addresses were signed so address arithmetic makes sense. KymFarnik 03:08, 2 April 2007 (UTC)
When I was at Waikato University in the late 70s/early 80s, there was an 1130 out the back. It was already obsolete then and had been replaced by a PDP 11/70 and an 11/34. It was fascinating, with this great big back panel covered in blinking lights, and the golf-ball typewriter, and great big disk cartridges that seemed to hold about 3 bits of information! For the fun of it I wrote a 4x4x4 noughts and crosses game on it in Fortran (I think) - it worked pretty well, although it relied on reprinting the position after each move. I don't think I've got a listing of it any more, though. I have since written a new game in Delphi (nDm) loosely based on it to run under Windows. Pedrocelli 01:11, 18 September 2007 (UTC)
When I started at Kingsport Press in August 1969 in the Tape Data Processing department, TDP was running type composition on an IBM 1130. Manuscripts were keyed to paper tape on Friden Flexowriters, font setwidths were stored as card decks, and the justified and hyphenated output paper tapes from the composition program on the 1130 were used to drive Mergenthaler Linotype linecasters. Paper tapes from the Cafeteria cash registers were also processed on our 1130 for payroll deductions of cafeteria charges. Compared to the IBM 360 in MIS, our 1130 was cute. Naaman Brown ( talk) 15:22, 4 May 2009 (UTC)
I also remember it well ... I was one of the authors of the EMU-IBM 1130 Fortran Compiler. I still have a copy of the user manual we wrote as documentation for our users. It started as an attempt to produce better diagnostics; I took on the front end, working on the parser, while my colleague C. David Morse, looked into the object code generation. I was in my senior year, and Dave was a grad student. We obtained a copy of the source code from the computer center at the University of Michigan, who had bought the tape from IBM. What we got was a file cabinet full of punched cards - I think it was one deck of assembler code for each of 27 phases of the compiler. By the time we finished we had added two phases, and upgraded the compiler from Fortran II to Fortran IV. The work was carried out by Peter Diehr and C. David Morse, staff programmers for Instructional Computer Services of Eastern Michigan University.
Pdiehr (
talk)
12:53, 22 March 2011 (UTC)
The article states that the 1130 "became quite popular." I don't dispute that, but does anyone have information on how many 1130's were manufactured and/or shipped? Peter Flass ( talk) 17:17, 1 January 2012 (UTC)
I suggest that the program examples are very long, don't add anything to the article, and should be removed. Peter Flass ( talk) 01:35, 3 January 2012 (UTC)
I just looked at the programming examples. Are we allowed to have stuff which requires such attribution? - Denimadept ( talk) 22:45, 29 March 2012 (UTC)
Looking at the 360 article I see they list remaining systems, whether working or not. This should be included also for the 1130. Peter Flass ( talk) 01:35, 3 January 2012 (UTC)
Overall I like the recent edits by Spike-from-NH, but what's the distinction between "operating system" and "monitor?" The terms are often used interchangeably, e.g. "TOPS-10 monitor" is certainly an OS. On the other hand MS-DOS is considered an "operating system", and I would rate it about the complexity of DM2 or worse (DOS users usually did direct hardware video IO, bypassing the cruddy video support). I think the distinction is subjective. "Not complainin, just askin." Peter Flass ( talk) 13:16, 1 March 2012 (UTC)
What were the advantages of using LIBF rather than CALL? Peter Flass ( talk) 06:16, 3 March 2012 (UTC)
Re: "odd-looking "END START": I don't think that's odd -- don't all assemblers accept a start address on the END statement? Certainly all I'm aware of. [I know that's not your change, but you made me look...] Peter Flass ( talk) 17:27, 22 March 2012 (UTC)
end; {case}
and end; {record}
in Pascal although it does nothing. All of us ASM coders enjoyed the self-contradiction of END START
but it was hardly the only reason to name your program's starting point START. Again, my personal opinion is that the supposed irony doesn't add anything to the article, and I am on the fence as to whether the explanation of END START
appreciably helps anyone understand the example.
Spike-from-NH (
talk)
21:25, 23 March 2012 (UTC)I'm in a nitpickey mood today. The description of the sample assembler program saye "The printer, however, recognises text in 8-bit EBCDIC". This is true of the 1403; I had to look up the 1132 to check my memory, but technically the printer doesn't recognize anything. The print wheels are continuously running, and the 1132 continuously makes available to the CPU the code for the print wheel character in position to print next. An instruction of the print routine causes this code to be sent to the CPU. The routine compares this code with each character in the output record. Each time an equal is encountered, a bit is stored in the printer scan field
http://media.ibm1130.org/IBM%20227-3622-1%20FETO-MOI%201132%20printer.pdf
Peter Flass ( talk) 22:57, 22 March 2012 (UTC)
This section of the article should be reorganized. The final three items, on the derivation of "IBM 1130", are more like Apocrypha and deserve to be the final section. (They also deserve citation, or maybe omission.)
The first item, incompatibilities in object file formats, I'd delete as way outside the scope of the article.
The other items are not "oddities" but useful information directly related to information elsewhere in the article and ought to be moved. The second item (which belongs at the end of "Instruction set overview") is:
Relative addressing is akin to indexation, but is there any real evidence that IAR is best thought of as an "index register"? To what extent are 1, 2, and 3 not also "genuine hardware registers"? Spike-from-NH ( talk) 18:12, 1 April 2012 (UTC)
PS--And more questions. The table says the Model 4 runs at "3.6 μsec (70% performance)". The prose says "with a 5.6 µs cycle time". I can't reconcile these figures; which is correct? In what order are the columns of the table? Shouldn't they be in chronological order, which is also basically Model 1, 2, 3, 4, 5? Spike-from-NH ( talk) 00:38, 3 April 2012 (UTC)
Didn't the 1800 have real index registers? I think this was a difference between the 1130 and 1800. Peter Flass ( talk) 02:06, 4 April 2012 (UTC)
The 1800 did indeed have hardware registers for all four (or IAR + XR1-3) so that low memory was normal, but I've no idea what use might be made of memory locations 1-3 thereby released. NickyMcLean ( talk) 21:06, 4 April 2012 (UTC)
I think the 1620 was a precursor in that it was aimed at the same market - small scientific/engineering organizations. They were physically both desk-sized systems. Other than that, you're right. The 1620 and the 1130 were both about as similar as the 7090 and the 360, or the 1401 and the 360, but I think you could say the 7090 and 1401 were "precursors" of the 360, or maybe better, the 360 was a "successor" of them both. Peter Flass ( talk) 23:58, 4 April 2012 (UTC)
GeneOsten's edit to the article is correct; anyone following the article's External Links can download a PDF of the FORTRAN manual preceding Eastern Michigan's improvements, which billed itself not as FORTRAN II but "1130/1800 Basic FORTRAN IV". Spike-from-NH ( talk) 00:03, 18 September 2014 (UTC)
I can't seem to find information on how the LET/FLET entry identifies the disk location of the file. Also DUP documentation touches on "disk blocks" which seem to be separate from sectors but I can't find a definition. Peter Flass ( talk) 01:41, 7 February 2015 (UTC)
Regarding the revert war over the Fortran code example, I don't know and don't care about fortran
versus fortranfixed
, as ensuring that keywords and numerals appear in pretty colors does not help understanding. However, the last edit of
Cedar101 (reverted by
Denimadept) solved one problem: Interpreting as Fortran the numeric data at the end of the card deck imposed coloration that actively impeded understanding.
There is a fundamental problem here: The example is a deck of punched cards that includes Job Control Language (//), Fortran, and data and cannot be treated correctly in a single <source>...</source>
block.
Separately, youse should talk to each other (for example: below) and agree on the goal of your edits. Spike-from-NH ( talk) 13:10, 15 April 2016 (UTC)
I don't know what has changed, but parts of this article using <PRE>...</PRE>
, such as the instruction-set overview and some short code examples, are now being displayed in a variable-width font. This impedes understanding, as it prevents the columns from lining up.
Spike-from-NH (
talk)
14:44, 24 May 2016 (UTC)
OK, thanks for the check. My problem must be some local setting. Spike-from-NH ( talk) 16:33, 24 May 2016 (UTC)
I added a section listing existing 1130 systems. It would be nice for someone who knows to update the status: display/storage, working/non-working,, etc. or add any other existing systems. Peter Flass ( talk) 13:34, 13 July 2016 (UTC)
The section called Programming opens as if talking about FORTRAN and gets to LIBF. LIBF was more or less an IBM thing (per the PLM: "The cost, of course, is that XR3 is taken away from the user and the transfer vector is limited to 255 words"), and while one could code an ASM LIBF, it was atypical. It certainly wouldn't have been directly FORTRAN-callable. Reminds me... I wanted to add something to XR3, but ended up adding /0038.
LIBF invocations were from ASM code, or were generated by the FORTRAN compiler and hence were mostly invisible to the end-user (excluding rhose running disassemblers and reading core dumps) Pi314m ( talk) 09:28, 12 February 2017 (UTC)
2 matters, plus-
As to what edits to make... that's for the next edit. Pi314m ( talk) 05:43, 17 February 2017 (UTC)
Does anyone know when the production run ended? - Denimadept ( talk) 18:42, 7 November 2017 (UTC)
My university bought a 4K machine to go with its 16K machine. Student jobs desiring only to syntax-check a program were designated for the 4K machine. This is the basis of the text I added years ago that "The 1130 Fortran compiler could run on a machine with only 4,096 words of core—though the compiled program might not fit on such a machine."
So the article notes that the first phase of compilation "read the source statements into memory." On one hand, it is unremarkable that lines would be read into memory; you can't manipulate strings on disk. On the other hand, surely the entire program was not read into memory, from which it would be handed off to subsequent phases, as this passage implies. If there was a temporary file passed from phase to phase, wouldn't this fact be more crucial than listing what the first phase does? Spike-from-NH ( talk) 14:55, 27 January 2019 (UTC)
Without a Compiler PLM handy, this may seem like WP:OR, but I liked IBM's use of phases, including for DM2, since it allowed patching and adding phases to track system "date" (there was none, unless added locally), user accounting, and other tricks borrowed from the 360 arena. Pi314m ( talk) 22:45, 28 January 2019 (UTC)
Just as an aside, the space-squeezing techniques made it impossible for the compiler to see the problem with:
(which is why programs like Lint (software) were written.
"Lint"-type programs could see the spaces, but the compiler saw it as
Note the next sentence "The compiler was available in a disk-resident version as well as on 8-channel punched paper tape or punched cards." - systems without a disc drive facility could not use temporary storage (since card readers/punchers and paper tape don't do "rewind and re-read" very well), thus the card-only systems for assembler really did require a second pass of the card deck through the reader/punch. I'm happy not to have suffered this arrangement on an 1130, but on an IBM1620 at Auckland University, which did not have a disc system, there was indeed temporary output to a deck of cards which had to be read in for the compiler's second pass and then discarded. Lots of cards. Cringe. Also, the cards of its symbol table output (the last part of the intermediate output card deck) had to be found and placed at the start of the deck to be read, since otherwise, forwards references (that were finalised only when the last source statement had been read in the first pass) still could not be resolved in the second pass if it were at the end of the deck. It was the last phase of the 1130's Fortran compiler that could write the finalised relocatable machine code it had developed in memory - to cards, paper tape, or to the disc drive.
I vaguely remember occasional problems when the compiler ran out of memory during its processing, not just in its input phase - some phases caused an increase in the size of the representation of the code as compilation proceeded and the phases "massaged" the internal representation, and this resulted in pained scrutiny of the size, number, complexity and prolixity of FORMAT statements or possibly the splitting of the source (subprogram or main prog.) into parts which would then require some sort of arrangement to share data. Simply changing the size of arrays would not help with the problem of source code complexity and bulk. It was thanks to arrays that most often a prog. would not fit at run time. This problem promoted the re-use of variables for different purposes in different parts of a prog. rather than each part having its own properly-named variables, with obvious opportunities for mistakes. The corresponding encouragement of divide-and-conquer for the source code was countered by the increasing annoyance of arranging communication between the parts, and pragmatically, splitting a subprogram A into A1, A2, A3 meant that each had its own working storage that could not be shared (except via increasing dismay with COMMON storage arrangements and their risks) and since memory usage was static, the working storage required for A2 and A3 was consumed even though A1 was the only one active. Code storage could be shared with LOCAL (load-on-call) arrangements, but everyone preferred the faster-running offered by progs. that did not employ this.
At Victoria University Clive Nicholson and I modified the Fortran compiler's input phase so that instead of rejecting outright any source that had a statement with more than six (?) continuation lines, it would do so only if the squeezed representation of the continued statement exceeded the internal representation's statement length limit, which was the actual problem. Thereby, a complex statement could be presented in some sort of semi-readable layout, perhaps. Persons engaged in Quantum Mechanical Computation liked high-order expressions, some similar in form to the expansion of (A + B)**i x (A - B)**j. for i and j up to nine in one case, where A**i actually meant A(i), etc.. I should have written a prog. to produce the expansions. Instead, the student and his professor worked through them by hand, as did I when checking. Ah well. NickyMcLean ( talk) 10:21, 30 January 2019 (UTC)
A recent edit mentioned that the PDP-8 was “smaller, cheaper, and better-selling” than the 1130. Smaller and better-selling are obvious, but how did similarly-configured systems compare in price? The 1130 came with a 1MB disk, 65KB on RAM, and 1050 console printer and usually (IME) a card-reader/punch and 80lpm printer. I think the PDP-8 usually came with nothing. Also, it looks like the -8 was faster, but how did the two systems compare on benchmarks? Peter Flass ( talk) 00:36, 27 April 2020 (UTC)
1973: Xerox had a 530 at a trade show. People stopped by. 530s were bought by 1130 shops. The success stories of the 530, however, were not enough to offset that the 560s apparently didn't do as well. Pi314m ( talk) 01:49, 17 September 2020 (UTC)
The section "reserved memory" has the SAC interrupting on IL1,2,3,4,5. Attachment Channel RPQ description lists only IL4. It makes sense that it would use only one interrupt level. I believe the SCA used IL3. I guess the info in the article as written comes from "Functional Characteristics.": p.16 Can anyone clarify? I don't want to make changes unless someone else agrees. Peter Flass ( talk) 14:56, 28 May 2023 (UTC)
As far as I know, the 1130 Fortran IV compilers follows what the Fortran 66 standard calls "Basic Fortran". That is, the subset is defined in the standard. Among others, it allows only five letters for variable names. I have the 1130 version of IBM's ECAP, which is written that way. They took all the six letter variable names and replaced the middle two letters with Z. Also, it doesn't have the LOGICAL type and LOGICAL IF statement. Gah4 ( talk) 05:12, 10 May 2024 (UTC)
![]() | This article is rated Start-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | |||||||||||||
|
Earlier drafts referred to the 16thbit being used for indirect addressing. That is incorrect. The indirect bit is in the instruction format, not the address. Addressing was 15bits (32K 16bit WORDS), addresses were signed so address arithmetic makes sense. KymFarnik 03:08, 2 April 2007 (UTC)
When I was at Waikato University in the late 70s/early 80s, there was an 1130 out the back. It was already obsolete then and had been replaced by a PDP 11/70 and an 11/34. It was fascinating, with this great big back panel covered in blinking lights, and the golf-ball typewriter, and great big disk cartridges that seemed to hold about 3 bits of information! For the fun of it I wrote a 4x4x4 noughts and crosses game on it in Fortran (I think) - it worked pretty well, although it relied on reprinting the position after each move. I don't think I've got a listing of it any more, though. I have since written a new game in Delphi (nDm) loosely based on it to run under Windows. Pedrocelli 01:11, 18 September 2007 (UTC)
When I started at Kingsport Press in August 1969 in the Tape Data Processing department, TDP was running type composition on an IBM 1130. Manuscripts were keyed to paper tape on Friden Flexowriters, font setwidths were stored as card decks, and the justified and hyphenated output paper tapes from the composition program on the 1130 were used to drive Mergenthaler Linotype linecasters. Paper tapes from the Cafeteria cash registers were also processed on our 1130 for payroll deductions of cafeteria charges. Compared to the IBM 360 in MIS, our 1130 was cute. Naaman Brown ( talk) 15:22, 4 May 2009 (UTC)
I also remember it well ... I was one of the authors of the EMU-IBM 1130 Fortran Compiler. I still have a copy of the user manual we wrote as documentation for our users. It started as an attempt to produce better diagnostics; I took on the front end, working on the parser, while my colleague C. David Morse, looked into the object code generation. I was in my senior year, and Dave was a grad student. We obtained a copy of the source code from the computer center at the University of Michigan, who had bought the tape from IBM. What we got was a file cabinet full of punched cards - I think it was one deck of assembler code for each of 27 phases of the compiler. By the time we finished we had added two phases, and upgraded the compiler from Fortran II to Fortran IV. The work was carried out by Peter Diehr and C. David Morse, staff programmers for Instructional Computer Services of Eastern Michigan University.
Pdiehr (
talk)
12:53, 22 March 2011 (UTC)
The article states that the 1130 "became quite popular." I don't dispute that, but does anyone have information on how many 1130's were manufactured and/or shipped? Peter Flass ( talk) 17:17, 1 January 2012 (UTC)
I suggest that the program examples are very long, don't add anything to the article, and should be removed. Peter Flass ( talk) 01:35, 3 January 2012 (UTC)
I just looked at the programming examples. Are we allowed to have stuff which requires such attribution? - Denimadept ( talk) 22:45, 29 March 2012 (UTC)
Looking at the 360 article I see they list remaining systems, whether working or not. This should be included also for the 1130. Peter Flass ( talk) 01:35, 3 January 2012 (UTC)
Overall I like the recent edits by Spike-from-NH, but what's the distinction between "operating system" and "monitor?" The terms are often used interchangeably, e.g. "TOPS-10 monitor" is certainly an OS. On the other hand MS-DOS is considered an "operating system", and I would rate it about the complexity of DM2 or worse (DOS users usually did direct hardware video IO, bypassing the cruddy video support). I think the distinction is subjective. "Not complainin, just askin." Peter Flass ( talk) 13:16, 1 March 2012 (UTC)
What were the advantages of using LIBF rather than CALL? Peter Flass ( talk) 06:16, 3 March 2012 (UTC)
Re: "odd-looking "END START": I don't think that's odd -- don't all assemblers accept a start address on the END statement? Certainly all I'm aware of. [I know that's not your change, but you made me look...] Peter Flass ( talk) 17:27, 22 March 2012 (UTC)
end; {case}
and end; {record}
in Pascal although it does nothing. All of us ASM coders enjoyed the self-contradiction of END START
but it was hardly the only reason to name your program's starting point START. Again, my personal opinion is that the supposed irony doesn't add anything to the article, and I am on the fence as to whether the explanation of END START
appreciably helps anyone understand the example.
Spike-from-NH (
talk)
21:25, 23 March 2012 (UTC)I'm in a nitpickey mood today. The description of the sample assembler program saye "The printer, however, recognises text in 8-bit EBCDIC". This is true of the 1403; I had to look up the 1132 to check my memory, but technically the printer doesn't recognize anything. The print wheels are continuously running, and the 1132 continuously makes available to the CPU the code for the print wheel character in position to print next. An instruction of the print routine causes this code to be sent to the CPU. The routine compares this code with each character in the output record. Each time an equal is encountered, a bit is stored in the printer scan field
http://media.ibm1130.org/IBM%20227-3622-1%20FETO-MOI%201132%20printer.pdf
Peter Flass ( talk) 22:57, 22 March 2012 (UTC)
This section of the article should be reorganized. The final three items, on the derivation of "IBM 1130", are more like Apocrypha and deserve to be the final section. (They also deserve citation, or maybe omission.)
The first item, incompatibilities in object file formats, I'd delete as way outside the scope of the article.
The other items are not "oddities" but useful information directly related to information elsewhere in the article and ought to be moved. The second item (which belongs at the end of "Instruction set overview") is:
Relative addressing is akin to indexation, but is there any real evidence that IAR is best thought of as an "index register"? To what extent are 1, 2, and 3 not also "genuine hardware registers"? Spike-from-NH ( talk) 18:12, 1 April 2012 (UTC)
PS--And more questions. The table says the Model 4 runs at "3.6 μsec (70% performance)". The prose says "with a 5.6 µs cycle time". I can't reconcile these figures; which is correct? In what order are the columns of the table? Shouldn't they be in chronological order, which is also basically Model 1, 2, 3, 4, 5? Spike-from-NH ( talk) 00:38, 3 April 2012 (UTC)
Didn't the 1800 have real index registers? I think this was a difference between the 1130 and 1800. Peter Flass ( talk) 02:06, 4 April 2012 (UTC)
The 1800 did indeed have hardware registers for all four (or IAR + XR1-3) so that low memory was normal, but I've no idea what use might be made of memory locations 1-3 thereby released. NickyMcLean ( talk) 21:06, 4 April 2012 (UTC)
I think the 1620 was a precursor in that it was aimed at the same market - small scientific/engineering organizations. They were physically both desk-sized systems. Other than that, you're right. The 1620 and the 1130 were both about as similar as the 7090 and the 360, or the 1401 and the 360, but I think you could say the 7090 and 1401 were "precursors" of the 360, or maybe better, the 360 was a "successor" of them both. Peter Flass ( talk) 23:58, 4 April 2012 (UTC)
GeneOsten's edit to the article is correct; anyone following the article's External Links can download a PDF of the FORTRAN manual preceding Eastern Michigan's improvements, which billed itself not as FORTRAN II but "1130/1800 Basic FORTRAN IV". Spike-from-NH ( talk) 00:03, 18 September 2014 (UTC)
I can't seem to find information on how the LET/FLET entry identifies the disk location of the file. Also DUP documentation touches on "disk blocks" which seem to be separate from sectors but I can't find a definition. Peter Flass ( talk) 01:41, 7 February 2015 (UTC)
Regarding the revert war over the Fortran code example, I don't know and don't care about fortran
versus fortranfixed
, as ensuring that keywords and numerals appear in pretty colors does not help understanding. However, the last edit of
Cedar101 (reverted by
Denimadept) solved one problem: Interpreting as Fortran the numeric data at the end of the card deck imposed coloration that actively impeded understanding.
There is a fundamental problem here: The example is a deck of punched cards that includes Job Control Language (//), Fortran, and data and cannot be treated correctly in a single <source>...</source>
block.
Separately, youse should talk to each other (for example: below) and agree on the goal of your edits. Spike-from-NH ( talk) 13:10, 15 April 2016 (UTC)
I don't know what has changed, but parts of this article using <PRE>...</PRE>
, such as the instruction-set overview and some short code examples, are now being displayed in a variable-width font. This impedes understanding, as it prevents the columns from lining up.
Spike-from-NH (
talk)
14:44, 24 May 2016 (UTC)
OK, thanks for the check. My problem must be some local setting. Spike-from-NH ( talk) 16:33, 24 May 2016 (UTC)
I added a section listing existing 1130 systems. It would be nice for someone who knows to update the status: display/storage, working/non-working,, etc. or add any other existing systems. Peter Flass ( talk) 13:34, 13 July 2016 (UTC)
The section called Programming opens as if talking about FORTRAN and gets to LIBF. LIBF was more or less an IBM thing (per the PLM: "The cost, of course, is that XR3 is taken away from the user and the transfer vector is limited to 255 words"), and while one could code an ASM LIBF, it was atypical. It certainly wouldn't have been directly FORTRAN-callable. Reminds me... I wanted to add something to XR3, but ended up adding /0038.
LIBF invocations were from ASM code, or were generated by the FORTRAN compiler and hence were mostly invisible to the end-user (excluding rhose running disassemblers and reading core dumps) Pi314m ( talk) 09:28, 12 February 2017 (UTC)
2 matters, plus-
As to what edits to make... that's for the next edit. Pi314m ( talk) 05:43, 17 February 2017 (UTC)
Does anyone know when the production run ended? - Denimadept ( talk) 18:42, 7 November 2017 (UTC)
My university bought a 4K machine to go with its 16K machine. Student jobs desiring only to syntax-check a program were designated for the 4K machine. This is the basis of the text I added years ago that "The 1130 Fortran compiler could run on a machine with only 4,096 words of core—though the compiled program might not fit on such a machine."
So the article notes that the first phase of compilation "read the source statements into memory." On one hand, it is unremarkable that lines would be read into memory; you can't manipulate strings on disk. On the other hand, surely the entire program was not read into memory, from which it would be handed off to subsequent phases, as this passage implies. If there was a temporary file passed from phase to phase, wouldn't this fact be more crucial than listing what the first phase does? Spike-from-NH ( talk) 14:55, 27 January 2019 (UTC)
Without a Compiler PLM handy, this may seem like WP:OR, but I liked IBM's use of phases, including for DM2, since it allowed patching and adding phases to track system "date" (there was none, unless added locally), user accounting, and other tricks borrowed from the 360 arena. Pi314m ( talk) 22:45, 28 January 2019 (UTC)
Just as an aside, the space-squeezing techniques made it impossible for the compiler to see the problem with:
(which is why programs like Lint (software) were written.
"Lint"-type programs could see the spaces, but the compiler saw it as
Note the next sentence "The compiler was available in a disk-resident version as well as on 8-channel punched paper tape or punched cards." - systems without a disc drive facility could not use temporary storage (since card readers/punchers and paper tape don't do "rewind and re-read" very well), thus the card-only systems for assembler really did require a second pass of the card deck through the reader/punch. I'm happy not to have suffered this arrangement on an 1130, but on an IBM1620 at Auckland University, which did not have a disc system, there was indeed temporary output to a deck of cards which had to be read in for the compiler's second pass and then discarded. Lots of cards. Cringe. Also, the cards of its symbol table output (the last part of the intermediate output card deck) had to be found and placed at the start of the deck to be read, since otherwise, forwards references (that were finalised only when the last source statement had been read in the first pass) still could not be resolved in the second pass if it were at the end of the deck. It was the last phase of the 1130's Fortran compiler that could write the finalised relocatable machine code it had developed in memory - to cards, paper tape, or to the disc drive.
I vaguely remember occasional problems when the compiler ran out of memory during its processing, not just in its input phase - some phases caused an increase in the size of the representation of the code as compilation proceeded and the phases "massaged" the internal representation, and this resulted in pained scrutiny of the size, number, complexity and prolixity of FORMAT statements or possibly the splitting of the source (subprogram or main prog.) into parts which would then require some sort of arrangement to share data. Simply changing the size of arrays would not help with the problem of source code complexity and bulk. It was thanks to arrays that most often a prog. would not fit at run time. This problem promoted the re-use of variables for different purposes in different parts of a prog. rather than each part having its own properly-named variables, with obvious opportunities for mistakes. The corresponding encouragement of divide-and-conquer for the source code was countered by the increasing annoyance of arranging communication between the parts, and pragmatically, splitting a subprogram A into A1, A2, A3 meant that each had its own working storage that could not be shared (except via increasing dismay with COMMON storage arrangements and their risks) and since memory usage was static, the working storage required for A2 and A3 was consumed even though A1 was the only one active. Code storage could be shared with LOCAL (load-on-call) arrangements, but everyone preferred the faster-running offered by progs. that did not employ this.
At Victoria University Clive Nicholson and I modified the Fortran compiler's input phase so that instead of rejecting outright any source that had a statement with more than six (?) continuation lines, it would do so only if the squeezed representation of the continued statement exceeded the internal representation's statement length limit, which was the actual problem. Thereby, a complex statement could be presented in some sort of semi-readable layout, perhaps. Persons engaged in Quantum Mechanical Computation liked high-order expressions, some similar in form to the expansion of (A + B)**i x (A - B)**j. for i and j up to nine in one case, where A**i actually meant A(i), etc.. I should have written a prog. to produce the expansions. Instead, the student and his professor worked through them by hand, as did I when checking. Ah well. NickyMcLean ( talk) 10:21, 30 January 2019 (UTC)
A recent edit mentioned that the PDP-8 was “smaller, cheaper, and better-selling” than the 1130. Smaller and better-selling are obvious, but how did similarly-configured systems compare in price? The 1130 came with a 1MB disk, 65KB on RAM, and 1050 console printer and usually (IME) a card-reader/punch and 80lpm printer. I think the PDP-8 usually came with nothing. Also, it looks like the -8 was faster, but how did the two systems compare on benchmarks? Peter Flass ( talk) 00:36, 27 April 2020 (UTC)
1973: Xerox had a 530 at a trade show. People stopped by. 530s were bought by 1130 shops. The success stories of the 530, however, were not enough to offset that the 560s apparently didn't do as well. Pi314m ( talk) 01:49, 17 September 2020 (UTC)
The section "reserved memory" has the SAC interrupting on IL1,2,3,4,5. Attachment Channel RPQ description lists only IL4. It makes sense that it would use only one interrupt level. I believe the SCA used IL3. I guess the info in the article as written comes from "Functional Characteristics.": p.16 Can anyone clarify? I don't want to make changes unless someone else agrees. Peter Flass ( talk) 14:56, 28 May 2023 (UTC)
As far as I know, the 1130 Fortran IV compilers follows what the Fortran 66 standard calls "Basic Fortran". That is, the subset is defined in the standard. Among others, it allows only five letters for variable names. I have the 1130 version of IBM's ECAP, which is written that way. They took all the six letter variable names and replaced the middle two letters with Z. Also, it doesn't have the LOGICAL type and LOGICAL IF statement. Gah4 ( talk) 05:12, 10 May 2024 (UTC)