#Small code
17 messages in this thread
Larry, How bout we start a thread on how to make Lattice executables or Manx
executables or Modula 2 executables as small as possible ? For example, we
could start with a small program uploaded in a library with a make file showing
how it was built and then propose that people upload there versions of the same
code slightly modified but still recognizable, and the make file used to build
it and see how small we can get it. See who can make it the smallest and then
document the techniques to use for each language. Also we could maybe get the
various compiler vendors to upload their guidelines and suggestions for how to
code to get the most out of their language. What do you think. Yes?/No?
Paul Montgomery
Paul,
I moved your question about small code into the programming section
(10) where those interested in programming can see it and startup the thread if
they so desire.
Don
Thanks. Paul Montgomery
Paul, Here are some things I do to limit size of executables with Lattice 4.0.
This in no way encompasses all ways of reducing code size, but it's a start.
1. If you don't want the stack checking code or the features of the
lattice stdio functions, you can link with AStartup.obj instead
of c.o. In order to do this, you need to:
a. Remove <lattice/stdio.h> include from your source code.
b. If you need to use the limited stdio features of Amiga.lib then
declare extern LONG stdin, stdout, stderr;
c. Compile with the -v option of LC.
d. Link with AStartup.obj instead of c.o and list Amiga.lib first
in your list of libraries.
NOTE: If you have the 1.2 Dev update, look at the doc file in
the startups dir. Also, check out the limited features
for doing stdio with Amiga.lib.
2. You can also use PC relative addressing ( -r compiler option )
for smaller programs.
3. For small programs you can use the SC option of the linker to
combine all code hunks into one. This will reduce the size of
the resulting executable file.
I haven't had a chance yet to play with Base register relative data
addressing (-b compiler option) or the short integers (-w compiler option)
features of 4.0 yet.
<Glenn
Glenn,
Whats the differences, between Astartup.obj and CBack.obj ? Is Astartup
referenced by both Cback and C.O or is it a replacement for them ? If it is
referenced by Cback and C.o, what does it give you that you couldnt write
yourself ? or is it startup code that you would have to do anyway but is
provided for you. ( and is better written ). Where can I find what exactly is
needed to be done by a program ( bare bones, no other included code ( compile
time, or link time ), other than external references to data values, to lets
say open a window and then print hello world using either the Graphics routine
Text or intuitions PrintIText ?? If that program is called from the CLI as
opposed to from Workbench, what differences are there ? What a mouthfull.
Thanks
Paul
Paul, well, Astartup.obj is one of several startup modules for the front end of
C ( or even Assy ) programs that are started from the CLI or WorkBench. Others
that I know of include c.o, cback.o, TWstartup.obj, Lstartup.obj, and I'm sure
there are others floating around. Which one you use depends on what you need
done on startup for your main program module. I'm not going to list the
features of them here. You can look at the source code for them to see what
they accomplish for you. Or, you can even write your own. The Basic types of
things that they perform are things like:
Opening the dos.library
Setting up stdin, stdout, stderr
Determining where program was started from (WB or CLI)
For further info, there is a discussion about startup in the RKM's.
If you are unsure, you could stick with c.o until you are more familiar with
the startup & program environment. BTW, there might be a C example of a 'Hello
World' in the DL's. If not, there is one in the Intuition Manual.
Good Luck, <Glenn
One really has to be very careful when changing the startup module, and
sensitive to which library functions are being used and which compiler options
are used and/or defaulted. This is not to say that it can't or shouldn't be
done, only that there are many hidden gotcha's. As an example, using the
lattice '-b' compile option to produce base-register-relative addressing for
global data areas is now the default (with 4.0), but most of the 'alternate'
startups don't set up the appropriate register (A4) with the address of the
global data segment (or is it the address of the global data segment + 32K??).
Experiment away, but be prepared for problems.
..Bob
Bob, of course you need to be carefull. As with anything, you can't
effectively use different startup modules unless you understand what they do
for you, and how it affects your compiler environment. And nothing says that
you can't write your own startup module to meet your program needs. I have
done this for programs which get LoadSeg()'d. Your right tho, it isn't for the
novice doing his first 'Hello World' program. As for Astartup.obj, I have used
it in place of c.o to significantly reduce the size of the resulting program.
Using different startup modules is no different than using the different
compiler switches with Lattice 4.0, you will have difficulties if you don't
understand what it does.
<Glenn
Glenn,
Where in the RKM does it discuss startup of application code ? The
example of 'hello world' I am suggesting would be one not to learn how to
program, but one to explore the different ways one could code it to get the
most or the least out of one compiler. Be it MANX, lattice or even any of the
Modula 2 compilers. Different examples of compile and link strings showing
what effect they have in terms of size and speed is something along the lines
of what I trying to stir up here. On disk 4 of the lattice 4.0 distribution
disk there was a file called AMIGAN_EXCERPT that had some good examples. I
dont know if its legal to upload it but it might be a good starting point for
lattice, Are there other such examples in the MANX and MD2 world ???
Paul
Paul, The section on WorkBench discusses application startup and has an
example of a startup module. I also recommend looking at the Assembly source
for the startup module you are interested in. Ok, I hadn't seen the excerpt
from the Amigan on the Lattice disk. There are some good pointers there for
reducing code size. I'm not familiar with Manx or Mod II, so no comment.
As far as taking one small program and tweaking it down to get the smallest
code, I don't feel that would give results that would be useable. What methods
you use to reduce code size will be dependent on the program itself. Such
things as program size, function calls used, etc, will determine what methods
are effective to reduce the size of that program. There isn't just one method
that will always work for reducing code size and increasing speed. If there
were, the compilers would be optimized to always use those means.
I don't mean to sound negative, but it really is something that is
individual and unique for each program and programmer.
Of course, if you have the time, you could write it all in assembly, fresh
and new each time, and have the fastest and smallest programs.
<Glenn
Glenn,
Agreed, it is up to the individual programmer to determine the techniques
that are usable in their particular situation. But, without knowledge of as
many of the techniques as possible, How can he/she make a decision as to which
one is applicable. What I was looking for was a source for as many ideas as
possible as to how one can tailor the environment one is running in, to
optimize it. ( for speed, size, ease of maintenance, or whatever applies. )
The information I had in hand was not understood by myself well enough to take
full advantage of it. I hoped that this forum would be a source of ideas that
I could experiment with to see if they were useable in different projects I am
involved in. ( and it has. ). My understanding of those techniques ( with your
help ) has grown considerably, but I still have a few questions. For instance,
on disk 4 extras/tricks/avail.c in the compile string at the head of the file
an assignment of DEFINE _stdout=_echo is made. What is _echo ? Also if you get
the chance to download small.arc, in small6.map there are two other bits of
code pulled in that I dont know why they are there or where they come from.
Any ideas. Thanks for all of the help
Paul
Paul,
I downloaded and use your dearc program — very nice! One feature
request tho, how about assuming a .arc extender if one isn't there? Much like
UnArc does?
Steve,
Why not.. I'll see what I can do. Thanks for the pat on the back. Did you
download dearc or dearc2? dearc2 includes source if I take to long to upload
the change.
Paul
Paul, I couldn't find small.arc in the DL's. I looked at avail.c on Disk 4 of
Lattice 4.0. Seems that there are some interesting, undocumented tricks going
on in the first 5 lines of avail.c. Did you read the Read.Me file in the same
directory? Some interesting stuff!
After looking it over, 'echo' on the first line of avail.c seems to do two
things. When you execute avail.c, it prints a blank line. When avail.c is
compiled it declares 'echo' to be an int. Since LC seems to do this
automagically, they use the int 'echo' for holding the value of stdout required
for the printf statements in avail.c. Notice the line
echo = int(Output());
in avail.c. printf wouldn't know where to send it's output if stdout wasn't
defined, hence the 'DEFINE _stdout=_echo' argument for blink. The only reason
I can see for doing this is to save 4 bytes in the final program.
<Glenn
P.S. I'm picking up a few things from this thread myself!
Glenn,
The concept of executing the source file to have it compile I though (
though = thought ) was great and have adopted it on other systems. It is great
concept for use in maintaining code. Also good for unit testing individual
modules in a product. Set up compile and link string at top for using the
module as a standalone entity and then have compile pragmas to compile in test
code needed to test functions of module. That way if you run across a bug
later in system test, you can always pull module recompile it as standalone, (
by execute ), and test. Neat also because you can have module compile one way
when compiled by make file for system and compile with other options or pragmas
when module is executed.
Now I see what _echo was for.. Yup just to save code. Small.arc should be
in the Programming library, I uploaded it late last week, Maybe it will appear
soon.
Paul
Glenn, I uploaded a file called small.arc to dl 9 today. Check it out is ( is
= if ) if you can. It takes a small program from 4.5+K to around 530 bytes.
Thanks for the help.
Paul
Sounds good to me Paul. Reducing code size is always of interest to
programmers.
Regards, Larry.