Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Program refuses to compile
#18
boriel Wrote: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).

Funny, I was trying to use the compiler without all the pointers and pokes and ran into nothing but walls and bugs and POKE was never removed from QBASIC or Visual BASIC 1.0 for DOS but it was removed I think for the Windows versions. I can very well live without OOP like I said, to be considered. No I am not asking for C in BASIC
but the opposite. For instance, I hate the C-style loops. But OOP can be useful if the compiler handles arrays like objects internally, one ERASE command and the OVERALL array descriptor is gone. Then I can use: SAVE "Contents"DATA MyArray() and the DIM for it is Dim MyArray(0 to 7,0 to 31) as STRING and lets say that the array is 7K long, then the program saves that seven K with the overall array container. Then the container/descriptor is at the base for the array pointers and then comes the array if uninitialized with the length of each element as one preceded of course with the two byte len descriptor for each element. If I assign a two byte string to a element then there is shifting or relocation. The idea behind REDIM is that one of the routines in it should have a array compactor/reallocator. Not exactly OOP
but something aking to it, to treat each array as an independent block transparent to the programmer like it was in QBASIC. Like I said, I could live without OOP and I do not really care for it in an 8bit compiler or for a minimalistic computer like the ZX or the old 8 bit machines. TYPEs are a different matter and then it helps to treat them as blocks as well and the min length of one for an uninitialized element could be ten or user specified. They had the number ten in the old days if I remember correctly or maybe that was the number of array elements. It could not even be one in the two byte len descriptor itself but instead just a reserved memory zone of ten bytes for each element of stated zero in length. I was working with fixed length array elements each five bytes or letters in size then it is better to have the reserved len user
specified. To load the array back then the DIM must match. This is what I am talking about, a friendly high level manner.

Memory banks could be handled like plug in with extensions for each machine, carefully designed so the overall structure of the *concept* of memory banks fits all machines with the same overall extensions for every machine BUT the implementations of those extensions is different for each machine. The ZX 128K is not the only machine with extra memory banks. So it is a matter of a good plug in model to encapsulate the idea of banks with a good model of fixed extensions to it to actually implement it on each machine. The backpatching will still be done by the compiler, no chance there. But if you are dealing with files compiled with the ROM switch then of course the backpatching addresses into ROM will change so a good dynamic list for the compiler is important. People then can write a part of their own plugins for different machines making your job easier.

I hope that you find some 32bit routines for the Z80 to make it at least a user definable option if to go 32bit or 40bit for the ZX but if it is already converted to 40bit from 32bit then you can't be that far from a full fledged 32bit FP format plus what I have seen in the asm files for the compiler.

But OOP is out and that is good, after Microsoft's small basic and Scratch for Linux then I would let the kids use ZX BASIC to get a real feel for BASIC coding and compiler usage and a low level feel, an ASM feel even on how computers really work. Something that is entirely missing in today's world. Or beginners in computer learning.

Hey, maybe even disk routines can be written using some sort of a plug in structure and all of those routines use the heap.

An idea at least.
Reply


Messages In This Thread

Forum Jump:


Users browsing this thread: 2 Guest(s)