Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Program refuses to compile
#16
A very long (and hard :oops: ) msg.
I will answer it in chunks
Darkstar Wrote:To me this is bare minimum. Note I did not go into asking for support for TYPEs, a standard fare with QBASIC; or UNIONS, or OOP or a switch from 40bit floats to 32bit floats and that should lessen ZX ROM dependency making the compiler even more retargetable to other machines than it is right now. Nor am I asking for that all commands to use the heap like both of the SAVE and LOAD commands as that lessens even more the dependency of platform specific configurations and not to mention it makes the compiler more consistent. And I did not ask for more input/output choices like the ability to deal with 128K disks and RAM disks or even the disk systems that are available for the 48K machine. Put all of that together then you have a real usable compiler, well, maybe apart from OOP and UNIONS, that reaches beyond the bare minimum. After that UNIONS and OOP and 128K memory management and the support for the PLAY command can be considered to make an outstanding compiler.

These for points summarize the problems to achieve what you are saying:
  • * Putting OOP is not only complex, but also add some serious overhead (memory, speed), for an 8 bit compiler. In fact What you are asking for is C. Yes, you want C with BASIC keyboards. BASIC did never had OOP (it was a BASIC language for learner), and all that come later (mainly by Microsoft) are a derivation to modern languages. Some people ask for pointers, tamplates, and all the stuff C++ has. ¿Seriously? Do this make ZX BASIC a "better" compiler or language? Many learners are already having troubles using current features (e.g. undeclared variables, nexted scopes allowed in the last version and the like). And add such complex things just because they're cool or because they're using in 1 or 2 proyects is not worth the hassle. This is what I discussed in the FreeBasic forum.

    IMHO its better to have powerful data structures (list) in a friendly high level manner (no pointers). Many modern languages don't use pointers, why should ZX BASIC do so? BASIC was *never* intended for that (yes, POKE was removed from modern BASIC dialects, like VBASIC and QBASIC).

    * Supporting memory banks internally makes the compiler very platform dependable, and definitely much more complex. This has already been discussed, and the simplest approach is to mimic LOAD! and the similar commands, with external functions (.bas files with inline asm). Trying to mimic a "linear memory model" with the ZX Spectrum RAM scheme is, IMHO, a waste of time. Not only is complex, but also makes the compiler infinitely more hard. Each block code must be "measured" (in size) and rearranged (e.g. backpatching during linking phase which is currently done by the assembler itself).

    * For the FP format, 32 bits is not "faster". In fact, the 32 bits FP standard is temporarily converted to 40 bits in a format very similar to the one used by the FP ROM. FP ROM was used both for memory saving and compatibility purposed. I've been reading (and looking for) 32 bits FP routines for Z80 and haven't found anything of interest (any help will be welcome in this area).
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)