"Lars Hansen" <lars.o.hansen gmx.de> writes:

I know it's slightly <insert-what-you-think-after-you've-read-the-source>, but
which commandline options to sc (and which type of app. (16-bit, 32-bit)?)
yield the fastest executing code (on AthlonXP) (I assume there is not much
free room for inefficient code, but anyway, for such a tiny program i just
like to know) of the following C source:


#include <dos.h>
#include <stdio.h>

int main(void)
 {
  FILE *f;
  char b[4];
  struct date d;

  getdate(&d);

  b[3]=d.da_day%10+4);
  d.da_day/=10;
  b[2]=d.da_day%10+48;

  b[1]=d.da_mon%10+48;
  d.da_mon/=10;
  b[0]=d.da_mon%10+48;

  f=fopen("rt.html","a");
  fseek(f,71,SEEK_SET);
  fwrite(b,sizeof(char),4,f);
  fseek(f,138,SEEK_SET);
  fwrite(b,sizeof(char),4,f);
  fclose(f);

  return 0;
 }

roland <--rv ronetech.com> writes:

Tiny

roland


Lars Hansen wrote:

 I know it's slightly <insert-what-you-think-after-you've-read-the-source>, but
 which commandline options to sc (and which type of app. (16-bit, 32-bit)?)
 yield the fastest executing code (on AthlonXP) (I assume there is not much
 free room for inefficient code, but anyway, for such a tiny program i just
 like to know) of the following C source:
 
 
 #include <dos.h>
 #include <stdio.h>
 
 int main(void)
  {
   FILE *f;
   char b[4];
   struct date d;
 
   getdate(&d);
 
   b[3]=d.da_day%10+4);
   d.da_day/=10;
   b[2]=d.da_day%10+48;
 
   b[1]=d.da_mon%10+48;
   d.da_mon/=10;
   b[0]=d.da_mon%10+48;
 
   f=fopen("rt.html","a");
   fseek(f,71,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fseek(f,138,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fclose(f);
 
   return 0;
  }
 
 
 

"Lars Hansen" <lars.o.hansen gmx.de> writes:

yea, the memory model, but what about optimization options?

"Walter" <walter digitalmars.com> writes:

I suspect that the execution of your program will be dominated by the time
it takes to write the file, and that any optimizations settings will have no
measureable affect on the total time.

But in general, for running under DOS, your best bet for speed would be
small model (-ms) and use -o for optimization. For programs too large to run
under the s model, use the 32 bit dos extender model (-mx).

"Lars Hansen" <lars.o.hansen gmx.de> wrote in message
news:b2is58$16kk$1 digitaldaemon.com...
 I know it's slightly <insert-what-you-think-after-you've-read-the-source>,

but
 which commandline options to sc (and which type of app. (16-bit, 32-bit)?)
 yield the fastest executing code (on AthlonXP) (I assume there is not much
 free room for inefficient code, but anyway, for such a tiny program i just
 like to know) of the following C source:


 #include <dos.h>
 #include <stdio.h>

 int main(void)
  {
   FILE *f;
   char b[4];
   struct date d;

   getdate(&d);

   b[3]=d.da_day%10+4);
   d.da_day/=10;
   b[2]=d.da_day%10+48;

   b[1]=d.da_mon%10+48;
   d.da_mon/=10;
   b[0]=d.da_mon%10+48;

   f=fopen("rt.html","a");
   fseek(f,71,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fseek(f,138,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fclose(f);

   return 0;
  }

"Lars Hansen" <lars.o.hansen gmx.de> writes:

"Walter" <walter digitalmars.com> schrieb im Newsbeitrag
news:b2jnv0$kg4$1 digitaldaemon.com...
 I suspect that the execution of your program will be dominated by the time
 it takes to write the file, and that any optimizations settings will have no
 measureable affect on the total time.

yes, that's probably true. If there is one "fastest solution", I just wanted
to know whether the compiler is capable of "delivering" that for these type of
small (in my case tiny) programs.


 But in general, for running under DOS, your best bet for speed would be
 small model (-ms) and use -o for optimization. For programs too large to run
 under the s model, use the 32 bit dos extender model (-mx).

Ok, thank you.


2 other questions:

What does 16-bit code actually mean? No usage of extended registers like EAX
etc. and just AX...?

Is there are possibilty to specifically optimize for certain processor types
(P,PIII, K7) by some option which tells the compiler which alignment or
special instruction set to use?


Lars


P.s.: sorry for perhaps "out-of-place" REs, but Outlook Express doesn't RE to
c++.dos.16-bits because of "no newsgroup selected"; perhaps a character
problem.

"Walter" <walter digitalmars.com> writes:

"Lars Hansen" <lars.o.hansen gmx.de> wrote in message
news:b2m92v$2ofi$1 digitaldaemon.com...
 What does 16-bit code actually mean? No usage of extended registers like

EAX
 etc. and just AX...?

The CPU runs in 2 modes, 16 bit and 32 bit. You can use EAX in 16 bit mode,
but it requires special instructions. 16 bit code also uses 16:16
segment/offset addressing, severely limiting the memory that can be
addressed.


 Is there are possibilty to specifically optimize for certain processor

types
 (P,PIII, K7) by some option which tells the compiler which alignment or
 special instruction set to use?

Yes, see the -2, -3, -4, -5, -6 switches to the compiler.

"Lars Hansen" <lars.o.hansen gmx.de> writes:

the following program compiled with sc "sourcefilename" produces a program
which does the following:

appends b at end of file, places b at file offset 138

it should place b at file offset 71 and 138  (b is the char array)

(also compiling with -o or -mtd produces this wrong code)

Also two qs:
1. when compiled with -mt there's the optlink warning 23 "No Stack": so does
the compiler not generate pushes or will they result in code loss?
2. when compiling with -mtd x.n filenames are shortened to x.3 filenames
(x<8)resulting in the file rt.htm created by the program. Is there a
workaround?


dmc version 8.29n


Lars


 #include <dos.h>
 #include <stdio.h>

 int main(void)
  {
   FILE *f;
   char b[4];
   struct date d;

   getdate(&d);

   b[3]=d.da_day%10+48;
   d.da_day/=10;
   b[2]=d.da_day%10+48;

   b[1]=d.da_mon%10+48;
   d.da_mon/=10;
   b[0]=d.da_mon%10+48;

   f=fopen("rt.html","a");
   fseek(f,71,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fseek(f,138,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fclose(f);

   return 0;
  }

"Walter" <walter digitalmars.com> writes:

To write files in binary you need a "b" in the fopen call, as in
fopen("rt.html","ab"). Next, COM programs don't have a stack segment in the
executable, that's why the linker produces a warning. The program will still
work correctly, if you follow the COM conventions for stack usage (i.e. use
very little stack). Third, 16 bit programs cannot handle file names other
than 8.3. "rt.html" is not a valid 16 bit filename. Try "rt.htm".

"Lars Hansen" <lars.o.hansen gmx.de> wrote in message
news:b2mhq8$2vp9$1 digitaldaemon.com...
 the following program compiled with sc "sourcefilename" produces a program
 which does the following:

 appends b at end of file, places b at file offset 138

 it should place b at file offset 71 and 138  (b is the char array)

 (also compiling with -o or -mtd produces this wrong code)

 Also two qs:
 1. when compiled with -mt there's the optlink warning 23 "No Stack": so

does
 the compiler not generate pushes or will they result in code loss?
 2. when compiling with -mtd x.n filenames are shortened to x.3 filenames
 (x<8)resulting in the file rt.htm created by the program. Is there a
 workaround?


 dmc version 8.29n


 Lars


 #include <dos.h>
 #include <stdio.h>

 int main(void)
  {
   FILE *f;
   char b[4];
   struct date d;

   getdate(&d);

   b[3]=d.da_day%10+48;
   d.da_day/=10;
   b[2]=d.da_day%10+48;

   b[1]=d.da_mon%10+48;
   d.da_mon/=10;
   b[0]=d.da_mon%10+48;

   f=fopen("rt.html","a");
   fseek(f,71,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fseek(f,138,SEEK_SET);
   fwrite(b,sizeof(char),4,f);
   fclose(f);

   return 0;
  }