thread repost: Discussion on Parser/UI Options

[debrouxl]

Very informative, indeed
Nitpick: I think you meant "lex/yacc".

Quote:I don't know why they chose the 68K but it the end they not only had to pick just a subset of Derive, but to rewrite it in C (probably there's a fair amount of assembler there too).

AFAWCT, the amount of pure assembly code in the TI-68k series' OS is relatively small.
Only lower-level stuff (a subset of the startup code, idle code, some interrupt handler / "trap" software interrupt subroutines, subroutines of the self-test code), the BCD floating-point code, several 32-bit / 32-bit division and modulo routines, and probably several other small bits that I'm forgetting about at the moment, are definitely written in ASM, because they use special instructions which can't be produced from C, and/or special calling conventions, or (rarely) special optimization tricks that only human ASM programmers would use.

However, even routines such as memcpy or memset aren't written in assembly: any half-decent human would never produce an optimization blunder that at least one of these routines contains. The higher-level CAS functionality is written in C, with special macros or special compiler support for the decidedly non-C calling convention of the core floating-point subroutine.
One of the most egregious and infamous pessimizations produced by that toolchain is a number of triplets of consecutive identical instructions for swapping two 16-bit halves of the same 32-bit data register.

Quote:How did they solve that with the 92/89? My guess is that they are running everything symbolic and the approximate mode/results are something having to do with the APPROX Derive function. That is an option.

Indeed, unless the user sets approximate mode in the settings, or temporarily forces it with DIAMOND + ENTER, computations are usually done with the symbolic engine when in AUTO or EXACT mode. The symbolic engine occasionally falls back to numeric it it can't deal with something.