Hi!
20-Ноя-2004 20:50 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> troubles, like was issued with RTL-multiplcation functions from OW.
BO> That was a different problem. Watcom generated NEAR calls to these
BO> functions. Relocation wouldn't help. This point is moot now with one CS,
BO> and anyway I like our own versions better :)
Yes, me also liked our multiplication. :)
>> The more
>> so, now they may be moved from low/nonrelocatable part (in kernel.asm) into
>> resident part! (Do you remember, how I was try to move Borland's RTL
>> functions into resident part and forget about relocations?)
BO> Yes you could move these into the resident part if you do runtime
BO> patching. But is it worth the effort for a secondary compiler?
But there already present code for patching (in MoveKernel())! Just
expand it for the second table. No "secondary compiler".
BO> I will not stop you trying to do this, but I see it as a waste of time
BO> myself (other than an exercise in patching).
Unfortunately, my current new machine is not very stable and hangs when
active disk usage. :( This is another reason why now I so inactive in FD
development.
Anyway, do you have ideas, how to detect position of RT-buffer inside
executable in exeflat? For example, this buffer may be prepended by unique
signature (like "RtBuF", and the byte with size of buffer). Any other ideas?
>> >> PS: Bart, some time ago you decrease kernel by reordering object files.
>> >> May
>> >> you explain what was changed and how you find this?
>> BO> Just reordered by placing more or less similar files close together (asm
>> BO> close to asm, c close to c); that decreased entropy so compression
>> BO> improved.
>> Only compression? I remeber something about reduced executable size,
>> but without words about compression.
BO> No it was only compression, how else can reordering save space?
Can. For example, issue is with segments alignment, which makes
"slacks" at end of segments. Reordering segments (through object files) may
allow to eliminate those slacks. At least, I encounter such effect with
BC/TASM/TLINK.
BO> The trick to reduce uncompressed executable size was only obtained using a
BO> different default calling convention via #pragma.
-------------------------------------------------------
This SF.Net email is sponsored by: InterSystems CACHE
FREE OODBMS DOWNLOAD - A multidimensional database that combines
robust object and relational technologies, making it a perfect match
for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8
_______________________________________________
Freedos-kernel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/freedos-kernel
