CompuServe Thread

#MODULA-2

7 messages in this thread
#42988From: Dec 9, 1986 11:03 AM
The SYM files may be big, but they are compiled and in an internal format, so they ought to be faster to include than all the C source code include files. -Joergen
#43062From: Steve FaiwiszewskiDec 9, 1986 9:31 PM
They OUGHT to be, but are they really? In my benchmarks, TDI M2 was much slower than Aztec C in compile time, and about the same as Lattice (sometimes even a bit slower). Check it out yourself, if you don't believe me. I don't know, but I'm guessing that some of its slowness is due to AmigaDos' slow disk access. Maybe on a hard disk it's a lot better, who knows? – Steve –
#43167From: Dec 10, 1986 9:52 AM
I just checked the .SYM files of the TDI compiler. It amazed me, that a hex dump revealed strings as INT-CARD and CHAR. It seems, that the format is only semi-compiled. If they changed that, they could save some space and speed up compilation, I should think. -Joergen
#43219From: Steve FaiwiszewskiDec 10, 1986 7:30 PM
I don't know if you noticed, but suppose you have a definition file where you have to declare anything which require you to import from another .Sym file (say Intuition), then all of the imported .Sym file is incorporated into yours. For example: DEFINITION MODULE Foo; FROM Intuition IMPORT WindowPtr; VAR wp : WindowPtr; END Foo. Try to compile this. First of all, it takes the compiler eons to generate the Foo.Sym file: it just sits there apparently twiddling its thumbs (actually, it's probably resolving some references), and once in a while writes something to disk. Next, look at the size of Foo.Sym!!! It's humongous!!!! Now try to decode it (using DecSym, if you have it). It seems as if all of Intuition.Sym is in here. Now, to me, it seems like a lousy way to implement this. Les, is this a bug or a feature? Will this be changed for 1.2? – Steve –
#43300From: Dec 11, 1986 9:45 AM
Yes, Steve, I did notice this. They must be able to cut down on the amount of data stored in the .sym files, but also we must remember, that everything which can be referenced through a pointer must be there. We have the problem of versions involved here. When your Foo module was compiled it relied on the version of Intuition at that point in time. That cannot be substituted by a simple reference to include Intuition, whenever the .sym file is used. -Joergen
#43431From: Steve FaiwiszewskiDec 12, 1986 12:06 AM
Why not just store the version number of Intuition.Sym, in Foo.Sym? – Steve –
#43493From: Dec 12, 1986 10:18 AM
The primary reason for not just storing the version no. of another definition module in a .sym file must be "easier version control". By making a .sym file self contained you only need to keep the latest version of your .sym files and not ALL versions just in case another definition module would reference it. When would you need to use different versions ? E.g. whenever you change the record layout in a database. In the new programs you access the old records through the types and procedures of the old .sym file and the new records through the new .sym file. -Joergen