Sidetracking from 'Tabs vs. Spaces': Do you indent assembly code?
-
No. Probably because the early assemblers I learned on didn't support it: column zero starts were a label, column 7 started an opcode, column 15 was a parameter. And also because it wouldn't have worked in most cases: spaghetti code is a "feature" of much assembly code (since you are trying to cram as much function into as little ROM space or processing time as possible) and you can't indent that in a meaningful way.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
OriginalGriff wrote:
column zero starts were a label, column 7 started an opcode, column 15 was a parameter.
Sounds like PLAN (ICL 1900 Assembler) which I spent several years writing. Col 1 = label, col 7 = op code, 13 = accumulator(s), 17 = operand, 36 = comment, 73 to 80 = sequence number The sequence numbers were vital. It was the only way of reconstructing a source program if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
-
OriginalGriff wrote:
column zero starts were a label, column 7 started an opcode, column 15 was a parameter.
Sounds like PLAN (ICL 1900 Assembler) which I spent several years writing. Col 1 = label, col 7 = op code, 13 = accumulator(s), 17 = operand, 36 = comment, 73 to 80 = sequence number The sequence numbers were vital. It was the only way of reconstructing a source program if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
Oh gawd yes - dropped desk were a PITA. And you had to remember to leave gaps in teh sequence numbering so you could add code later ...
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
In the 'Surveys' section, there has been some assembler talk the last couple of days. It seems like we have fair share of developers not afraid of getting their fingers oily :-) I am curious: After more than 40 years of 'structured programming', do you assembler coders indent loop bodies, if-bodies / else-bodies etc. when you program such constructs in assembler? Or do you follow the tradition from 50 years ago, with every instruction/statement left justified?
-
No. It mostly impossible to indent in the way we do in C-like languages, because the way assembly flow works... Like in this code... No indentation makes sense here... However I use blank lines to break the code...
raster_irq: {
lda flag
and #popup_on
bne bottom // popup is activelda $d012 cmp #raster\_irq\_bottom\_line bcc topbottom:
lda #charset2 // set secondary charset (for bottom half of the screen)
sta $d018lda #raster\_irq\_top\_line sta $d012 jmp endtop:
lda #charset1 // set primary charset (for top half of the screen)
sta $d018lda #raster\_irq\_bottom\_line sta $d012end:
asl $d019 // clear pending
jmp $ea31 // finish interrupt
}"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
-
In the 'Surveys' section, there has been some assembler talk the last couple of days. It seems like we have fair share of developers not afraid of getting their fingers oily :-) I am curious: After more than 40 years of 'structured programming', do you assembler coders indent loop bodies, if-bodies / else-bodies etc. when you program such constructs in assembler? Or do you follow the tradition from 50 years ago, with every instruction/statement left justified?
The last time I wrote assembly code was on an XT box (8088 processor) using edlin. I barely remember what I ate for dinner yesterday, much less code from 40 years ago. I do remember loving to code that close to the hardware. And thanks for reminding me that I'm old as dirt. :laugh:
If you think 'goto' is evil, try writing an Assembly program without JMP.
-
No, of course not. Assembler was supposed to be hard to read, nothing should make it easier! I also didn't indent FORTRAN - but then it didn't lend itself to that.
- I would love to change the world, but they won’t give me the source code.
-
No. Probably because the early assemblers I learned on didn't support it: column zero starts were a label, column 7 started an opcode, column 15 was a parameter. And also because it wouldn't have worked in most cases: spaghetti code is a "feature" of much assembly code (since you are trying to cram as much function into as little ROM space or processing time as possible) and you can't indent that in a meaningful way.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony "Common sense is so rare these days, it should be classified as a super power" - Random T-shirt AntiTwitter: @DalekDave is now a follower!
-
In the 'Surveys' section, there has been some assembler talk the last couple of days. It seems like we have fair share of developers not afraid of getting their fingers oily :-) I am curious: After more than 40 years of 'structured programming', do you assembler coders indent loop bodies, if-bodies / else-bodies etc. when you program such constructs in assembler? Or do you follow the tradition from 50 years ago, with every instruction/statement left justified?
Never, always been a tab then the op code. Labels start in the first column.
"the debugger doesn't tell me anything because this code compiles just fine" - random QA comment "Facebook is where you tell lies to your friends. Twitter is where you tell the truth to strangers." - chriselst "I don't drink any more... then again, I don't drink any less." - Mike Mullikins uncle
-
Looks indented to me.
OP was talking about if- and for-like structures... The only indentation here is labels vs code...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
-
OP was talking about if- and for-like structures... The only indentation here is labels vs code...
"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
I see no such specification.
-
No. It mostly impossible to indent in the way we do in C-like languages, because the way assembly flow works... Like in this code... No indentation makes sense here... However I use blank lines to break the code...
raster_irq: {
lda flag
and #popup_on
bne bottom // popup is activelda $d012 cmp #raster\_irq\_bottom\_line bcc topbottom:
lda #charset2 // set secondary charset (for bottom half of the screen)
sta $d018lda #raster\_irq\_top\_line sta $d012 jmp endtop:
lda #charset1 // set primary charset (for top half of the screen)
sta $d018lda #raster\_irq\_bottom\_line sta $d012end:
asl $d019 // clear pending
jmp $ea31 // finish interrupt
}"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
Kornfeld Eliyahu Peter wrote:
because the way assembly flow works...
No, I see no reason whatsoever why assembly flow works differently from flow in 'structured languages'. The advantages of while- and for-loops, function definitions, if/else, switch etc. lies not in the source language keywords, but in the structured nature of your solution, which is independent of implementation language. That includes assembler. In my student days, at a Tech University, some of the "hard engineering" departments stubbornly insisted that Fortran was The Only One Language for true engineers. This included the need for arbitrary GO TO jumps. E.g. indenting loops was meaningless, because a jump might break that loop structure. One of the professors wrote an article in the University newsletter were he fiercely attacked and ridiculed this silly idea of the Pascal programmers of moving code back and forth, right and left. That would only confuse the reader of the code, if code flow diverted from the indentation. I don't think I have ever programmed a goto in a block structured language; it has never appeared to provide any advantage whatsoever. I am thinking in terms of structured constructs even when programming in assembler. When I hear people arguing that assembler code "must" do it differently, my instinctive reaction is "So you want to program with GOTOs? What for??" It messes up program structure, makes maintenance more difficult, is error prone ... I, of course, use both conditional and unconditional when assembler coding. Some people reply: "Exactly! Look at yourself: A jump instruction is the same as a GOTO!" But no; I use the jumps in a structured way, the same way that a Pascal or C compiler would generate them, such as jumping back to the top of the loop for another iteration, jump past the loop when the termination condition is satisfied, or skipping over the if clause when the condition is false, or at the end of the if clause, skip over the else clause. Jumps are frequently required at block starts (opening brace, BEGIN in Pascal) and block ends (closing brace, END in Pascal), but never in the middle of a linear sequence. Short version: I strongly disagree that assembly program code flow differs from structured high level programming code flow. It is technically possible, as is goto-programming in Pascal or C, but you simply do not program that way,
-
I see no such specification.
-
OriginalGriff wrote:
column zero starts were a label, column 7 started an opcode, column 15 was a parameter.
Sounds like PLAN (ICL 1900 Assembler) which I spent several years writing. Col 1 = label, col 7 = op code, 13 = accumulator(s), 17 = operand, 36 = comment, 73 to 80 = sequence number The sequence numbers were vital. It was the only way of reconstructing a source program if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
jsc42 wrote:
if you (or, more commonly, the computer operator) accidentally dropped the deck of cards and you (always the programmer) had to re-order them back into their original sequence.
That was the purpose of the sequence number. If you had punched the card deck with sequence number in col 73-80, on the Univac mainframes running Exec-8 (later renamed OS-1100), you could read in the cards in any order; the machine would sort them according to the sequence number. That was of course no viable (although theoretically possible!) option if all cards were punched manually on a 026 card punch. I never saw anyone punching sequence numbers manually.
-
OriginalGriff wrote:
spaghetti code is a "feature" of much assembly code
Yep. See my signature line. :-D
If you think 'goto' is evil, try writing an Assembly program without JMP.
Of course you need JMP in assembler! You need it to skip that else clause, or return to the top of the loop. You just use it at the boundaries of logical code blocks, to implement the same semantics as the opening and closing braces of the equivalent C program.
-
The FORTRAN I used back in the day had everything in specific columns. So yeah, no indentions.
If you think 'goto' is evil, try writing an Assembly program without JMP.
Lots of Fortran programmers never knew: In cols 7 to 72, all spaces were insignificant. You could write GOTO or GO TO, COMM ON and SUB ROUTINE. Furthermore, no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123" The last Fortran I touched was a Fortran77 implementation. During the design discussions for Fortran77, with each proposed extension crazier than the other, one of the old gurus (Dijkstra?) remarked that "I do not know what programming languages will look like in year 2000, but they will be named Fortran!" When I stumbled across Fortran 2011, my immediate reaction was: "You were just so right, old Master!" I guess that Fortran of today both have significant spaces and reserved words. But I wouldn't be sure of it without checking the language specification. :-)
-
In the 'Surveys' section, there has been some assembler talk the last couple of days. It seems like we have fair share of developers not afraid of getting their fingers oily :-) I am curious: After more than 40 years of 'structured programming', do you assembler coders indent loop bodies, if-bodies / else-bodies etc. when you program such constructs in assembler? Or do you follow the tradition from 50 years ago, with every instruction/statement left justified?
Hmm. My last significant bit of assembly language was an OS/2 device driver written in Intel assembly language, flat memory model (yay!). There were a few places in the driver that implemented algorithms I originally (pseudo)coded in C. Those places tended to use indentation that resembled the original C. Indentation was not my practice throughout.
Software Zen:
delete this; -
Lots of Fortran programmers never knew: In cols 7 to 72, all spaces were insignificant. You could write GOTO or GO TO, COMM ON and SUB ROUTINE. Furthermore, no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123" The last Fortran I touched was a Fortran77 implementation. During the design discussions for Fortran77, with each proposed extension crazier than the other, one of the old gurus (Dijkstra?) remarked that "I do not know what programming languages will look like in year 2000, but they will be named Fortran!" When I stumbled across Fortran 2011, my immediate reaction was: "You were just so right, old Master!" I guess that Fortran of today both have significant spaces and reserved words. But I wouldn't be sure of it without checking the language specification. :-)
trønderen wrote:
no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123"
Oh barf.
Software Zen:
delete this; -
Kornfeld Eliyahu Peter wrote:
because the way assembly flow works...
No, I see no reason whatsoever why assembly flow works differently from flow in 'structured languages'. The advantages of while- and for-loops, function definitions, if/else, switch etc. lies not in the source language keywords, but in the structured nature of your solution, which is independent of implementation language. That includes assembler. In my student days, at a Tech University, some of the "hard engineering" departments stubbornly insisted that Fortran was The Only One Language for true engineers. This included the need for arbitrary GO TO jumps. E.g. indenting loops was meaningless, because a jump might break that loop structure. One of the professors wrote an article in the University newsletter were he fiercely attacked and ridiculed this silly idea of the Pascal programmers of moving code back and forth, right and left. That would only confuse the reader of the code, if code flow diverted from the indentation. I don't think I have ever programmed a goto in a block structured language; it has never appeared to provide any advantage whatsoever. I am thinking in terms of structured constructs even when programming in assembler. When I hear people arguing that assembler code "must" do it differently, my instinctive reaction is "So you want to program with GOTOs? What for??" It messes up program structure, makes maintenance more difficult, is error prone ... I, of course, use both conditional and unconditional when assembler coding. Some people reply: "Exactly! Look at yourself: A jump instruction is the same as a GOTO!" But no; I use the jumps in a structured way, the same way that a Pascal or C compiler would generate them, such as jumping back to the top of the loop for another iteration, jump past the loop when the termination condition is satisfied, or skipping over the if clause when the condition is false, or at the end of the if clause, skip over the else clause. Jumps are frequently required at block starts (opening brace, BEGIN in Pascal) and block ends (closing brace, END in Pascal), but never in the middle of a linear sequence. Short version: I strongly disagree that assembly program code flow differs from structured high level programming code flow. It is technically possible, as is goto-programming in Pascal or C, but you simply do not program that way,
I mostly agree with your view - JMP is not a GOTO equivalent, but most cases (in logically structured code) is the closing bracket of a block... However - in assembly indentation just makes less readable IMHO... Taking the same code sample, indentation makes it worst...
// if
lda $d012
cmp #raster_irq_bottom_line
bcc top// true branch
bottom:
lda #charset2 // set secondary charset (for bottom half of the screen)
sta $d018lda #raster\_irq\_top\_line sta $d012 jmp end// false branch
top:
lda #charset1 // set primary charset (for top half of the screen)
sta $d018lda #raster\_irq\_bottom\_line sta $d012// end if
end:"Everybody is a genius. But if you judge a fish by its ability to climb a tree, it will live its whole life believing that it is stupid." ― Albert Einstein
-
Lots of Fortran programmers never knew: In cols 7 to 72, all spaces were insignificant. You could write GOTO or GO TO, COMM ON and SUB ROUTINE. Furthermore, no tokens were reserved. You could name a SUBROUTINE FUNCTION or SUBROUTINE, to be called as "CALL FUNCTION(x)" or "CALL SUBROUTINE(y)". You could have a REAL variable named INTGEGER or REAL, and write statements such as "IF INTEGER.L T.REAL GOT 0123" The last Fortran I touched was a Fortran77 implementation. During the design discussions for Fortran77, with each proposed extension crazier than the other, one of the old gurus (Dijkstra?) remarked that "I do not know what programming languages will look like in year 2000, but they will be named Fortran!" When I stumbled across Fortran 2011, my immediate reaction was: "You were just so right, old Master!" I guess that Fortran of today both have significant spaces and reserved words. But I wouldn't be sure of it without checking the language specification. :-)
I also used Fortran77 in tech school. You're right, I don't recall them saying anything about spaces being ignored in those columns. One of my cousins created (or co-created, I don't remember) PDE2D using Fortran. The latest Windows version uses v11, and the Linux and Mac version use various flavors of GNU GFortran.
If you think 'goto' is evil, try writing an Assembly program without JMP.
