On at 2023-04-28 13:51 -0400, jer...@shidel.net wrote:
Hi All,
Logger is coming along great and I’m currently working on the final ALPHA-8
version. Once that is done, it will be time for a BETA or two. Then finally
version 1.0.
Your IISP headers could store the required retf at a place other than
after the header. This would save the short jump that you use to skip
the retf. If you put the int 2Dh handler right after the resident device
strategy handler, you could re-use the strategy handler's retf for the
int 2Dh IISP header. Likewise the int 10h IISP header if it is close enough.
In my IISP header macro, iispentry [1], I can pass a label to use for
the retf in one of the parameters. Also, it now by default aligns the
IISP header to a word-boundary to slightly speed up accesses of the
ieNext pointer.
It is good that your ieEntry jump already is the expected 10EBh, a jump
to what I call ieStart. This is required for fully standard IISP
headers, and Ralf Brown's programs expect this exact value there.
Other than that I didn't look at all your code yet for more optimisations.
[1]: https://hg.pushbx.org/ecm/ldebug/file/ab7d7f8b72d5/source/AMIS.MAC#l44
For fun, I decided to implement a single binary compiler directive. When
enabled, it generates a single COM that acts as both the driver and interface
program. But, I am unsure if I will use that or the dual (SYS+COM) build for
the 1.0 release.
Mostly, it comes down to the size of the binary. At present, both the driver and
interface programs are UPX compressible. Their uncompressed size are about 3k &
6k respectively. So, when space may be tight on a boot floppy, the driver will only
need about 2.5k (UPX’d) of diskette space. Also if the interface program is used in
batch files to append debugging comment messages (not shown to the user) directly
to the log, it requires loading just the 4k (UPX'ed) interface program .
When compiled as a single COM for both the driver and interface, UPX
compression cannot be used and the binary is about 9k at present. Because there
is some common (or at least similar code) shared between the driver and
interface, this could most likely be reduced by 1 or 2k in some future version.
But that level of optimization will not happen anytime soon. I have other
things of much higher priorities that need doing.
So, the single COM will require almost 4 times the space of the dual binary
format. While it may not matter much for Hard Drives, CD-ROMs and USB sticks,
it could matter a lot for a floppy.
I guess for version 1.0, it could include the SYS and the single binary COM.
But, that could be confusing. Probably better to go with either the dual
binaries or just the single binary. And, I am leaning towards the dual binaries
for version 1.0.
I adjusted my inicomp stage slightly, originally an lDOS boot iniload
stage, to allow using it to compress the dual-mode (single binary)
Logger. First change was to allow setting up a stack based on the flat
.COM style entrypoint [2]. The second option is for a very small
optimisation that disables boot-loaded mode entrypoints into the stage
[3]. Then I modified Logger's log-drvr.asm to use the entrypoints
expected by inicomp for the device header [4].
During rebuilding Logger I found that a very recent NASM version, like
2.16 ish, is required to build. This is because you use the istruc
support of struc local labels, which was added to the standard macros in
[5]. Rebuilding also required to work around a new NASM problem [6]. The
new macros could be used in an older NASM as well, if you included some
%unmacro lines and the new macros in your sources. NASM is under the
2-clause BSD license [7] so you could copy their macros.
Here's the results of building my compressed dual-mode Logger
executable, compressed using LZIP (high ratio, slow) and LZSA2 (faster):
logger/BIN$ lzip -9vvfkc LOGGER.COM > logger.lz
LOGGER.COM: 1.650:1, 60.62% ratio, 39.38% saved, 9240 in,
5601 out. logger/BIN$ nasm ../../inicomp/inicomp.asm -I
../../lmacros/ -I ../../inicomp/ -D_LZD -o loggerlz.com
-D_PAYLOAD_FILE="'logger.lz'" -D_IMAGE_EXE=1 -D_IMAGE_EXE_AUTO_STACK=0
-D_DEVICE=1 -D_DEVICE_ZERO_ENTRYPOINT=1 -D_DEVICE_ATTRIBUTE=8000h
-D_DEVICE_NAME="'LOGGERxx'" -D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256
-D_IMAGE_EXE_GET_COM_STACK -D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0
../../inicomp/lzd.asm:698: warning: localvariables has 14688 bytes [-w+user]
../../inicomp/inicomp.asm:1320: warning: inilz: 2992 bytes used for
depacker [-w+user]
logger/BIN$ lzsa -c -f2 --prefer-ratio -v LOGGER.COM logger.sa2
Compressed 'LOGGER.COM' in 0.072056 seconds, 0.12 Mb/s, 1141
tokens (8.09816 bytes/token), 9240 into 6050 bytes ==> 65.4762 %
Compared 'logger.sa2' in 3.9e-05 seconds,
225.947 Mb/s logger/BIN$ nasm
../../inicomp/inicomp.asm -I ../../lmacros/ -I ../../inicomp/ -D_LZSA2
-o loggersa.com -D_PAYLOAD_FILE="'logger.sa2'" -D_IMAGE_EXE=1
-D_IMAGE_EXE_AUTO_STACK=0 -D_DEVICE=1 -D_DEVICE_ZERO_ENTRYPOINT=1
-D_DEVICE_ATTRIBUTE=8000h -D_DEVICE_NAME="'LOGGERxx'"
-D_IMAGE_EXE_CS=-16 -D_IMAGE_EXE_IP=256 -D_IMAGE_EXE_GET_COM_STACK
-D_BOOTLDR=0 -D_ALLOW_OVERLAPPING=0
../../inicomp/inicomp.asm:1320: warning: inilzsa2: 1392 bytes used for
depacker [-w+user]
logger/BIN$ ls -lgG
total 48
-rw-r--r-- 1 9240 May 1 11:10 LOGGER.COM
-rw-r--r-- 1 5601 May 1 12:21 logger.lz
-rw-r--r-- 1 8608 May 1 12:21 loggerlz.com
-rw-r--r-- 1 6050 May 1 12:21 logger.sa2
-rw-r--r-- 1 7456 May 1 12:21 loggersa.com
logger/BIN$
I'm not impressed, but at least it is a little savings. I tested the
files as both device driver and application mode executable. As you can
see, the LZSA2 executable is actually smaller than the LZIP one because
the LZIP depacker is much larger. For my usual use case of the lDebug
debugger (> 100 KiB), the bigger depacker costs less space than is saved
by the higher compression ratio.
A problem with my depackers as opposed to UPX's is that I do not take
advantage of the fact that Logger's binary is very small. Indeed, my
depackers support operation spanning more than 64 KiB of both the
compressed payload and the resulting decompressed program image. If I
took that out I could improve the depacker size.
And I am worse at size optimisation than the UPX people. But if they do
not yet provide support for dual-mode executables then my contribution
could still be useful to you.
[2]: https://hg.pushbx.org/ecm/inicomp/rev/aa0974fdd6e2
[3]: https://hg.pushbx.org/ecm/inicomp/rev/41860de1db0e
[4]:
https://github.com/ecm-pushbx/logger/commit/5cbd3b1f9548568458f92962e83cc0bdd7d61818
[5]: https://github.com/netwide-assembler/nasm/pull/40
[6]: https://bugzilla.nasm.us/show_bug.cgi?id=3392822
[7]:
https://github.com/netwide-assembler/nasm/blob/a916e4127b2eaa3bf40bddf3de9b0ceefc0d98a4/LICENSE
IDK.
On a side note…
I was playing with the single binary version and noticed some interesting things.
Under VirtualBox, I could even wait to load it post boot using DEVLOAD (high or
low). Which reported "1 char device installed. Driver Loaded.” and everything
worked fine.
But under DOSBox, DEVLOAD reports an “ERROR: free drive letter not found,
increase LASTDRIVE”. I get that it is DOSBox and did not expect it to work.
But, the driver is a char device and doesn’t use a drive letter. And, DOSBox
uses drive Z: for it’s pseudo-commands. So, it was not the error I was
expecting. Too be fair, I was expecting just a crash and not an error.
This is a DEVLOAD problem. It checks for the CDS unconditionally in its
preparation, I'd assume. There is a related error that it doesn't
install into CDS entries that are free, rather it finds the first free
one and assumes that all the ones after it are also free if the device
installs multiple block units.
Regards,
ecm
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
