ruud.baltissen_at_abp.nl
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.