The old Clipper 5 compiler had some fun error messages. The two that I remember running into were “Ford Maverick Error”, and my personal favorite, “Carnage! Module name crushed in compilation disaster!”. I ran across both abusing its preprocessor.
Some of the error messages produced by Apple's MPW C compiler (2006)
91–100 of 154 posts
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#92Earlier quoted context omitted.
I understand the arguments for unified RAM on a SoC, but it’s still a shame; even the new Mac Pro doesn’t have RAM slots.
The soldered-in SSD is worse, though. The SSD WILL wear out, so then you get to throw away your Mac?
> The SSD WILL wear out
This is by no means certain, certainly not enough to SHOUT about.
Modern SSDs have lifetimes that make them impractical to literally wear out, short of some kind of fault.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#93The old Clipper 5 compiler had some fun error messages. The two that I remember running into were “Ford Maverick Error”, and my personal favorite, “Carnage! Module name crushed in compilation disaster!”. I ran across both abusing its preprocessor.
I learned to program on various dBase languages. That Clipper 5 preprocessor was quite the thing! It reminds me of https://research.swtch.com/shmacro but it met a real need, lowering a COBOL-like syntax to a C/Pascal-like one.
(dBase code looks like https://github.com/harbour/core/blob/master/tests/ntx.prg , and https://github.com/harbour/core/blob/master/include/std.ch is an open-source reimplementation of Clipper's preprocessor definitions).
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#94I was programming on MacOS (the original) since it was possible. I remember many of these error messages! Especially "Too many errors on one line (make fewer)". ...also remember 45 minute builds when a header file changed.
In those days I wrote exclusively system extensions, plug-ins and XCMDs, using a mix of 68k, C and Pascal. Each project was quite small, so compile time was never a problem and MPW was a paradise. My largest XCMD actually had bits in all 3 languages which MPW happily linked together, and some projects had various little blocks of code to stick in the same file, all of which could be automated easily.
I remember these error messages coming up and laughing out loud when I saw the rare ones. Nice work, whoever did it!
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#95Earlier quoted context omitted.
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: this isn’t standard C (it uses void main , not int main ) 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.…
> Nitpick: this isn’t standard C (it uses void main, not int main)
You know what, I'm gonna nitpick that nitpick: void main() is fully allowed on a freestanding target, which is still standard C.
Given the C standards historically generous interpretation of undefined behaviour and other miscellany, I think it's a reasonable interpretation of the standard to pretend that a target that allows something other than int main(...) is freestanding rather than hosted, and therefore fully conforming.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#96"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.
FYI, Rust and many other modern languages do this.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#97My favorite error message was produced by the Univac Fortran V compiler, circa 1970: “Warning: floating point equality tests are nugatory.” I pride myself on my vocabulary, but I had to use the dictionary.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#98The old Clipper 5 compiler had some fun error messages. The two that I remember running into were “Ford Maverick Error”, and my personal favorite, “Carnage! Module name crushed in compilation disaster!”. I ran across both abusing its preprocessor.
I’m so curious, what could a Ford Maverick error possibly signify?
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#99Earlier quoted context omitted.
Binary size on a desktop OS is almost totally irrelevant in practice. Memory size matters a little more, but your OS will generally do a good job of loading what it needs (ie, huge binaries can still start quickly) and paging out what it doesn't. People have aesthetic complaints about "bloat", but again this is orthogonal to the actual speed of anything.
Well, the bloat has made many programs slower than they could be. Software is eating up the advances we get in hardware. Modern Word 365 is not any faster than Word 95 on a Pentium 66 in normal use. That is a ~100MHz computer with maybe 16MB RAM, and a rotating hard drive. Bloat making software bigger will in many cases also make it slower. Also, the UX on Windows 95 was consistent and easy to learn. Now, much softwa…
We need Stevesie to reincarnate and fire whoever is Scott-Forestall-ing it up this year.
Re: Some of the error messages produced by Apple's MPW C compiler (2006)
#100Earlier quoted context omitted.
I bet that sizeof(int)==2 - which immediately tells you everything you need to know - and the return value from a function has 8 bits in X and 8 bits in A. So ldx#0:txa is how you load a return value of (int)0. Regarding this specific unrolled loop, I would expect a 6502 programmer would just write the obvious loop, because they're clearly optimizing for space rather than speed when calling the ROM routine. They'll b…
We did a lot of loop unrolling and self modifying code back in the day, when making demos for the C64. The branch is really expensive. For example, clearing the screen you might use 16 STA adr,x and then add 16 to X before you branch to the loop.
Indeed, in some cases you want the unrolls. The 6502 is good in the twisties, but if you're trying to do any kind of copy or fill then the percentage of meaningful cycles is disappointingly low, and the unroll may be necessary. Also, if you're trying to keep in sync with some other piece of hardware, then just doing it step at a time can be much easier.
I have done a lot of all of this sort of code and I am quite familiar with the 6502 tradeoffs. But for printing 15 chars by calling a ROM routine, I stand by my comments.