[strags]

"GOAL never had a source-line debugger, as far as I know, although there's no reason it couldn't given some effort to write one."

Actually, it did. IIRC, the debug state required for converting run-time addresses to source lines was persisted in the compiler (which was a REPL, not a one-shot process like C), rather than exported in the form of symbols. The interface was pretty sketchy, but I'd say it was about as usable as GDB. You could set breakpoints, inspect registers, etc...

A lot of debugging was "live" though - since all the code was hot-loadable, you could just insert a debug print in the middle of a function on the fly. It was a really nice, iterative way to work.

[Arelius]

Since the entire thing was hot-loadable, how was the game linked, did every function call go through a indirection, or did you potentially re-link the entire program if the new function couldn't fit at the address of the old one?

[kayamon]

> did every function call go through a indirection

Yes.

[Arelius]

I wonder if that would still be an acceptable trade-off with high-performance games on modern memory architectures.

[kayamon]

My suspicion is "yes" -- the PS2 wasn't great at memory access, and modern CPU tend to have better caching/branch prediction anyway.

[sedachv]

No need to wonder. That is exactly how C++ vtables work.

[fla]

For virtual functions. Not all calls get an indirection. At least with any respectable compiler..

[sedachv]

Right, and how many game developers are recommending to "never use virtual functions because they are slow" in 2017? I remember seeing statements like that in Usenet posts and articles from the 1990s.

[Arelius]

Yeah, and in C++ one also avoids vtables when possible.

[kayamon]

Oh cool, I wondered if ND ever went to the trouble to write one or not. Thanks :)