41–50 of 154 posts
"Call me paranoid but finding '/*' inside this comment makes me suspicious" That, Sir, is none of your business.
...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
"Call me paranoid but finding '/*' inside this comment makes me suspicious" That, Sir, is none of your business.
...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
e.g. '/*' and '*/' would match each other, '/**' and '**/' would match, and so on.
That way, you would have full control of the depth of the comments, removing other comments wouldn't break the inner comments, etc.
I do run into the same issue you're describing, so I think there's value in the idea.
"a typedef name was a complete surprise to me at this point in your program" Ah, the joys of fun compiler messages. I miss those days. I remember getting one from a vendor compiler that was: "No! But they'll only let me warn you. Danger Will Robinson! Danger!" and: "Really! If you are fussing around with void *, just go home or at least back to your editor!" I think the IT manager kept that as a vendor just because o…
Not much of a C programmer, what's the context around void* being a big deal?
Dereferencing a void pointer has no meaning. The compiler can do anything it wants because it doesn't know how to interpret the memory. It could give you the correct thing, it could warp a civilization in from a distant planet, or it could open a world-ending black hole. All are equally probable.
Tangential to the content of the page: I really enjoyed how many MPW utilities generated output, including error messages, in the form of commands. Your terminal was an editor buffer, so you could cursor up (or click) on the appropriate line then press something like cmd-enter to pull up the file in question (among other things).
"Call me paranoid but finding '/*' inside this comment makes me suspicious" That, Sir, is none of your business.
...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
Earlier quoted context omitted.
Does it end that code with a jmp $fbfd ?
No. The compiler knows that trick for its own code :) not sure about introspecting into the assembly (I think LLVM doesn't do that). But either way, standard C returns int of 0 from main on success. So: ldx #0 txa rts
Nitpick 2: why ldx #0 txa rts? I would think lda #0 rts is shorter and faster
Back to my question: if it can’t, the claim “an assembler programmer couldn't do better” isn’t correct.
I think an assembler programmer for the 6502 would consider doing a jmp at the end, even if it makes the function return an incorrect, possibly even unpredictable value. If that value isn’t used, why spend time setting it?
A assembly programmer also would:
- check whether the routine at 0xFBFD accidentally guarantees to set A to zero, or returns with the X or Y register set to zero, and shamelessly exploit that.
- check whether the code at 0xFBFD preserves the value of the accumulator (unlikely, I would guess, but if it does, the two consecutive ‘l’s need only one LDA#)
- consider replacing the code to output the space inside “hello world” by a call to FBF4 (move cursor right). That has the same effect if there already is a space there when the code is called.
- call 0xFBF0 to output a printable character, not 0xFBFD (reading https://6502disassembly.com/a2-rom/APPLE2.ROM.html, I notice that is faster for letters and punctuation)
On a 6502, that’s how you get your code fit into memory and make it faster. To write good code for a 6502, you can’t be concerned about calling conventions or having individually testable functions.
I miss this kind of playfulness in computing. When I was at Amazon my manager told me that several years earlier he was responsible for updating the 404 page so he scanned a picture of a cat his daughter drew and made that the body of the page. In 2009 when I started, that was still the image, but at some point someone must have noticed and replaced it with a stock photo of a dog. The asset was still called kayli-kit…
> The compiler is 324k in size Playfulness isn't the only thing we've lost. Software bloat has reached comedic levels.
For some reason everyone prefers the newer software, though. Perhaps there’s more to it than binary size?
Earlier quoted context omitted.
Not much of a C programmer, what's the context around void* being a big deal?
Void pointers refer to anything and nothing. They are everything and all encompassing. What is pointed to by the void pointer could be what you want or it could be another universe. Dereferencing a void pointer has no meaning. The compiler can do anything it wants because it doesn't know how to interpret the memory. It could give you the correct thing, it could warp a civilization in from a distant planet, or it coul…
Earlier quoted context omitted.
...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
How about explicit depth levels, specified by asterisk count? e.g. '/*' and '*/' would match each other, '/**' and '**/' would match, and so on. That way, you would have full control of the depth of the comments, removing other comments wouldn't break the inner comments, etc. I do run into the same issue you're describing, so I think there's value in the idea.
Earlier quoted context omitted.
...I kind of wish compilers supported nested block comments. So if there's a /* inside of a /*, it would take two */'s to end it. Idk, maybe that would be a terrible idea in practice. But there are lots of instances where it would have saved me time.
You're probably looking for "#if 0" / "#endif".