Hi!
18-Ноя-2004 21:21 [EMAIL PROTECTED] (Bart Oldeman) wrote to
[EMAIL PROTECTED]:
>> Small optimization: because BC doesn't knows, that exit() doesn't
BO> I don't think optimizing exeflat.exe's size is very important though ;)
Sure. :) But why not make more optimal code from scratch in any case,
without thinking "will this code often used"?
>> LG> + qsort(reloc, header.exRelocItems, sizeof(reloc[0]), compReloc);
>> Why to spend extra time for sorting relocations?
BO> I think it's easier to read the output that way. Tom's idea.
BO> Does qsort() really take a long time for you in exeflat? I find that hard
BO> to believe, for just ~70 relocations.
Of course, qsort() if very fast algo (except some specific cases, when
it is O(N^2)), but why to do _any_ extra action, when unnecessary? :)
Especially, I suggest, (most) linkers do own sorting anyway?
Ok, ok, above questions are not critical and mostly rhetorical.
>> LG> + for (j = 0; j < silentcount; j++)
>> Never understand this option. (Though, don't try to study its meaning
>> deeper). The more so, me always annoying tons of some information about some
>> relocations, which garbaes output after exeflat.
BO> use a larger backscroll buffer. Anyway, seriously:
BO> The -S0x10 -S0x8B is outdated. 0x10 corresponds to segment 0x70 (device
BO> drivers etc) and 0x8B to the DOS data segment at 0xEB. However over the
BO> years some things were made smaller and the DOS data segment seems to be
BO> at 0xCF or 0xD0 depending on compilation options now.
...and different kernel branches. :)
BO> -S0x10 -S0x6F -S0x70
BO> will catch relocations from these segments. The idea to silence these is
BO> that these relocations are harmless because these segments don't move.
BO> Relocations to other segments may be bugs. With the above options you
Ok, I see. Thank you for exaplanation.
BO> should get something like
BO> relocation at 0x0000:0x0021 ->01d6 (far jmp to init code in kernel.asm)
BO> relocation at 0x01d6:0x9f2d ->0f2f (seg init_tos in kernel.asm)
BO> relocation at 0x01d6:0xa19c ->0000 (LowKernelConfig, main.c)
BO> relocation at 0x01d6:0xc21c ->01d6 (MoveKernel, FP_SEG(_HMATextEnd,
inithma.c)
BO> I checked them and these relocations are all fine. But if a fifth shows up
BO> unexpectedly we may have a bug.
Hm. I think for simplicity and safety, exeflat should itself move
relocation table from executable's header inside executable itself, so that
it may be reused by MoveKernel(). This allows to eliminate manual table at
kernel.asm:__HMARelocationTableStart.
(Yes, I know __HMARelocationTableStart is not plain relocation table,
but jump/code table, with jmps and calls to EnableA20. But table from header
may be copied (after fixing) into "secondary" table. This allows to make
code, which is more relocatable and may make cross-segments calls and
accesses. This also solves issues with standard library routines, which may
be used both from non-relocatable low code and from relocatable code.)
BO> ---
BO> UPXOPT seems indeed unnecessary now.
Sure. :)
PS: Bart, some time ago you decrease kernel by reordering object files. May
you explain what was changed and how you find this?
-------------------------------------------------------
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
