Hi,
(Sorry for being late to this discussion, I'm a bit backlogged.)
On Thu, May 2, 2024 at 7:05 PM Jim Hall via Freedos-devel
<freedos-devel@lists.sourceforge.net> wrote:
>
> On Thu, May 2, 2024 at 4:12 PM Eric Auer via Freedos-devel
> <freedos-devel@lists.sourceforge.net> wrote:
> [..]
> > *Runtime*
> >
> > Jim's version is a small C program, 120 lines, using catgets
> > for messages which can be translated in different languages.
> > The binary is a 22kB EXE (31kB without UPX). There were text
> > files with EN, RU, DE, HU and LV translations, I believe?
The latest version of Jim's on iBiblio appears to be 2.1d from 2005.
It has a "Borland TC makefile" using "-mm" (medium model? why?) and
-DNDEBUG in addition to linking to Kitten. The .EXE is 26 kb,
presumably UPX'd, and I'm guessing it uses floating point emulation
(which is unlikely to help much and is extra bloat that is totally
unnecessary for any Pentium or newer FPU-having cpus).
Not trying to nitpick (I've also been looking at old code of mine from
2013 called TIMEIT.C), but just FYI ....
1). his code isn't ANSI C89
= why include dos.h or process.h ? it says for exec() but uses
spawnvp(), I would normally prefer system()
= does that save memory? are we intentionally trying to avoid shelling
out to %COMSPEC% except for .BATs or built-ins?
= CLK_TCK is not ANSI (old 1988 POSIX???) and not at all preferred,
use CLOCKS_PER_SEC
2). Borland does use 64 kb of heap by default in the smaller data
models. To avoid that (and save a bit of memory, esp. since we're
shelling out), put "extern unsigned _heaplen = 1024;" and "extern
unsigned _stklen = 8192;" in your source. Try shelling out "mem /c" to
see the difference. (Maybe this is why he randomly chose "-mm" Medium
model?? Unnecessary, I'd just use Small.)
3). You really don't need printf() at all here (okay, maybe only for
Kitten ??). It doesn't matter as much for Turbo C, but even for
OpenWatcom it's like 6 kb. If you don't need floating point (see
below), you can make do with a simple "writelong()" routine and save
space. (Yes, I wrote such a routine, if you need it.) FYI, clock_t is
usually a typedef to a "long" integer.
4). In my program, I included both clock() and difftime(). My memory
(and notes) indicate that clock() was for integer times. You know, for
most simple uses, a round number of seconds elapsed is good enough
(and faster / smaller, no bloated and slow emulation lib or expensive
FPU needed). How often does 11 secs. versus 11.5 seconds matter?? A
naive Google search shows people advising to cast it to double! But
that defeats the whole point, IMHO. All the compilers I checked (about
a dozen) all have an integer value for CLOCKS_PER_SEC ... except Turbo
C! There it's 18.2 (for no good reason). Quick: undefine that and
redefine it to 18, that's good enough, IMHO. Or just use OpenWatcom.
> > My version is a small ASM program, made with NASM. It has
> > a main file, circa 450 lines, and a language include file,
> > circa 150 lines, which at the moment contains EN, DE, NL,
> > PT, ES, FR, TR, IT, PL and RU messages :-)
The 2012 version on iBiblio pointed to by Fritz was my unofficial hack
with EO (Esperanto) support.
Checking the latest "2024" version hosted online, it only adds HU but
omits EO. (That's fine if no one cares, but it feels like a
regression.)
> > As a task left as an exercise for the user, one could port
> > the C version to Tom's small KITTEN alternative to CATGETS.
2.1d from 2005 uses Kitten. The MAKEFILE.TC says this:
LDLIBS=kitten-b\kitten.obj
> > My preferred option would be to add HU and LV translations
> > to my small RUNTIME and use that instead of the big one ;-)
Most of that bloat can be removed in one of two ways:
1). use TC's -f87 or WCL's -fpi87 (mandatory hardware floating point
usage, no emulation)
2). use TC's -f- (avoid floating point entirely) only with
integer-friendly clock() and printf("%ld") code
> I wrote the Runtime program, so I guess I'll speak to that.
>
> This is a very old program. I don't remember why I wrote it, but I'm
> sure I was doing some debugging on a program and was trying to
> fine-tune the performance, and needed a way to test how long it took
> to run after making improvements.
A naive way would be to use "PROMPT $t" and leave a TEST.BAT without
any "@echo off", and just calculate the difference shown in your head.
FreeCOM also (non-standard) supports "time /t" to print the current time.
> There are lots of programs out there
> to track the run-time of a program on DOS, and I probably gave a quick
> look around
I forget what 4DOS uses. Some programming languages (e.g. QBASIC and
REXX) have easy timing built-in. DJGPP always had "REDIR.EXE -t", and
DJGPP's port of BASH has the standard *nix shell built-in "time"
command. (DJGPP's libc also has uclock() which tries to use Pentium's
RDTSC or automatically falls back to something else via SIGILL if that
fails).
> I'm in favor to swap out the old Runtime with this Runtime. No issues here.
One minor enhancement would be to consider stderr support. While it's
feasible that someone would want the elapsed time to (also) be
redirected with program output, more than likely they don't. (I did
make this optional in mine.)
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
