Date: 2002-10-08 10:34:23
Hallo John, Ullrich, Pasi, Thanks for your comments. J> If you move it and don't update *all* of the pointers, A pointer created by using "new/alloc" points to a table which on its turn contains the pointers to the actual data. Using this table I don't have to manipulate the program itself and also exactly know what data to manipulate. U> using indirect pointers (pointers to pointers) which is U> slow and generates larger code. I completely agree. But this is a feature meant for low memory systems. The choice is either a slower program or a program that doesn't run at all. J> and you might have pointers to fields inside it. U> does not use the double indirection in one place. These are a very good arguments and they worry me indeed :( But OTOH, if one writes weird code, he should expect weird bugs. But I will see it from the bright sight: if it cannot work, I won't have to implement it, thus saving myself some work :) J> Pascal, C, and C++ should be forgotten as quickly as possible. I disagree. The same argument is used in favour of above languages against ML and Basic. And still most programs on a C64 use these two specific languages. Why? Speed and/or memory. The only advantage of Basis is that its compiler is build in the OS and thus won't cost RAM. Any other compiler will cost RAM unless you replace the Basic-compiler (and run in compatibility problems). Pascal, C etc. are more suited for faster memory rich systems. But what is the gain? A shorter development time. Just measure how much time you need to write a simple program that only says "Hello world!" using Basic, Pascal, C or ML. Then measure how much memory the 'executable' needs. At last measure the time the executable needs to run. With ML you have two out of three on every machine and still one will use ML for the C64 and Pascal/C on a PC for particular reasons. Enough said I think :) U> Without a really big effort, it is not possible to U> automatically generate code for a banked system like the U> 720 to use more than one bank. I agree. I already said that I will use 4 byte pointers for manipulating data on 64+ KB machines: two bytes for the address within any given 64 KB block, the other two to code which block is meant. Taking the C64 as example, three bits are enough to tell the executable which bank is needed. A specific machine dependant module will take care of the actual actions needed to switch banks. One remark: if you know you will stay within one and the same bank, this module isn't needed, nor 4 byte pointers, thus saving extra memory for your own use. All the above covers data manipulation. For one problem I still haven't found solution: what if the executable code doesn't fit inside the first bank? (The first thing that came to my mind: Use another computer !!!) P> it seems to have expression tree generation and constant P> expression evaluation. Would you mind explaining what this is? (but I have the vague idea that I already invented the wheel for the second time) U> (if Ruud does not care that it's C) No. Any help is welcome. -- ___ / __|__ / / |_/ Groetjes, Ruud \ \__|_\ \___| http://Ruud.C64.org Message was sent through the cbm-hackers mailing list
Archive generated by hypermail 2.1.4.