dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (06/25/86)
It's more around 1K. The reason your lattice code is huge is that
the startup _main() uses quite a bit of stdio, and other stuff. This coupled
with the fact that Lattice does not know how to write libraries causes the
10-15K min. code size you usually get.
x.c:
main() { }
y.c:
main() { printf("x"); }
normal linker (using lattice normal startup) x y
code size 13896 14456
difference = 560 bytes. Now this makes you wonder what the hell lattice
has got in their startup that would create a 13896 byte executable for a
null program.
----------------
Note on amiga.lib's printf(). This is what you get when you don't use
lattice's stuff. I'm very glad the people who put together AMIGA.LIB
decided to put some standard calls in it. (THANK YOU!) What it means is
that we get printf() without going through lattice. In the amiga.lib
implimentation, remember that "%d" means a 'short' and "%ld" means a 'long'.
Thus, with the Lattice compiler, you must ALWAYS specify "%ld" or "%8lx" or
whatever.
Q to amiga people: just how complete is amiga.lib's printf()? .. it has
everything I've needed so far, but it would be nice to know it's limitations
without having to run into them.
-Mattmykes@3comvax.UUCP (Mike Schwartz) (06/25/86)
In article <8606242147.AA12273@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: > >difference = 560 bytes. Now this makes you wonder what the hell lattice >has got in their startup that would create a 13896 byte executable for a >null program. > >---------------- OK, so why does Lattice generate such large programs? Well, the answer is simple, and it sux having to deal with it by going around it, but... As far as I've seen, Lattice on the Amiga is a simple port of Lattice on the PC. Lattice prides themselves on the fact that they have all this portable stuff (I prefer libraries customized for the target machine, but when you want portability...). Lattice 'C' on the PC has the same problem with huge libraries. The cause is in their c.c, or startup.obj module. You see, they call exit() after the user main() returns, and exit() references a lot of other library routines that get dragged in and waste space. After using Manx for 5 months, I would bet that Lattice's code generation can't be any worse than the code generated with Manx's +L option. If some adventuresome soul wants to try and do something about it, there is a #define that Lattice uses in c.c called TINYMAIN, which is supposed to make smaller programs, but I'm pretty sure that even with TINYMAIN, exit() is called and programs are still inflated with a bunch of junk that is not needed. I hear that by mucking with c.c, it is possible to get decent sized compiled programs, but I have not spent the time to see what it would take on the Amiga version of Lattice. Good luck!
grr@cbmvax.cbm.UUCP (George Robbins) (06/26/86)
In article <8606242147.AA12273@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: > >difference = 560 bytes. Now this makes you wonder what the hell lattice >has got in their startup that would create a 13896 byte executable for a >null program. Well, if it's like lattice on the PC, using the default '_main' inludes stuff from stdio, and with lattice that means almost all of stdio on one big chunk. There was a time, now past, when lattice was the best C compiler available for the PC. Maybe they'll come to, someday... -- George Robbins - now working with, uucp: {ihnp4|seismo|caip}!cbmvax!grr but no way officially representing arpa: cbmvax!grr@seismo.css.GOV Commodore, Engineering Department fone: 215-431-9255 (only by moonlite)
rj@amiga.UUCP (Robert J. Mical) (06/27/86)
In article <8606242147.AA12273@pavepaws> dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) writes: >Q to amiga people: just how complete is amiga.lib's printf()? .. it has >everything I've needed so far, but it would be nice to know it's limitations >without having to run into them. Do believe that the requirement that every printf() arg be specified as long (eg %lx or %ld) is the only restriction/limitation.
aaron@uwmacc.UUCP (Aaron Avery) (06/27/86)
In article <556@3comvax.UUCP> mykes@3comvax.UUCP (Mike Schwartz) writes: >OK, so why does Lattice generate such large programs? Well, the answer >is simple, and it sux having to deal with it by going around it, but... > >The cause is in their c.c, or startup.obj module. You see, they call exit() >after the user main() returns, and exit() references a lot of other library >routines that get dragged in and waste space. After using Manx for 5 months, > >Good luck! I haven't tried it yet, and I'm probably totally off base, but replacing the exit() call in c.c with the AmigaDos Exit() call may (will) shorten things up, but I doubt it would work. People have said that they have used Astartup.obj and then put amiga.lib before lc.lib in the command line, but when I do that, I get unresolved variables in lc.lib. If I omit lc.lib completely, I get unresolved vars in Astartup.obj. I think it doesn't work if I put lc.lib first, either. Any ideas? Aaron Avery ({seismo,topaz,caip,allegra,ihnp4}!uwvax!uwmacc!aaron) (aaron%maccunix@rsch.wisc.edu) (aaron@unix.macc.wisc.edu)
claudio@ethz.UUCP (Claudio Nieder) (07/04/86)
Hello Matt,
you asked about printf and its restrictions. I disassembled AMIGA.LIB
and saw that there are a few of the stdio-routines. These
implementations use exec's private function "RawDoFmt" which does the
output conversion according to the format string.
RawDoFmt supports
- d signed decimal
- x hexadecimal
- s string
- c character
left- and right adjust and leading nulls are supported.
Below you find a small program running with the PD Modula-2 Compiler
which shows the use of RawDoFmt. The parameters of RawDoFmt are:
- a buffer
- the format string
- the pointer to the arguments (some kind of stack pointer)
- a subroutine to handle the output character, very flexible!
Note: RawDoFmt is a PRIVATE and UNDOCUMENTED exec-function, be carefull.
PS: With the PD Modula-2 Compiler (Fish Disk #24) a program that I wrote
to disassemble any object files of the amiga is included. The program
is called "ObjDump". I used this program to disassemble AMIGA.LIB
and LC.LIB and it was very informal to read this code.
Hope that helps,
from the home of the amiga modula-2 compiler
kussi
(******************************************************************************
Name : RawDoFmtTest.MOD
Version : 1.0
Purpose : Access To Exec's Private Procedure RawDoFmt
Author : ms
Created : 12.4.86 11:15 ms
Modified :
Comment : Used to implement c-procedure [s, f] printf
not all standard types are supported! no floating point args!
******************************************************************************)
MODULE RawDoFmtTest;
FROM Terminal IMPORT WriteString, Write, WriteLn;
FROM AMIGABase IMPORT Regs, LibCall, ExecBase;
FROM SYSTEM IMPORT ADR, LONG, ADDRESS;
TYPE Arguments = ARRAY [0..15] OF CARDINAL;
VAR s, st: ARRAY [0..127] OF CHAR;
args: Arguments;
PROCEDURE RawDoFmt(VAR s: ARRAY OF CHAR; format: ARRAY OF CHAR; args: ADDRESS);
VAR r: Regs; stuffChar: LONGCARD;
(* stuffChar is a routine that handles the output character stream,
here stuffChar stores the characters into the output string *)
BEGIN
format[HIGH(format)]:=0C;
stuffChar:=LONG(16C0H, (* MOVE.B D0, (A3)+ *)
4E75H); (* RTS *)
r.d[0]:=32;
r.a[3]:=ADR(s);
r.a[0]:=ADR(format);
r.a[1]:=args;
r.a[2]:=ADR(stuffChar);
LibCall(ExecBase(), -522, r);
END RawDoFmt;
BEGIN
WriteString('Using RawDoFmt to get formatted output'); WriteLn;
WriteString('======================================'); WriteLn; WriteLn;
args[0]:=000FFH;
args[1]:=0AAAAH;
args[2]:=01234H;
args[3]:=05678H;
RawDoFmt(s, "Hex Long: %8lx Hex Short: %5x Hex Leading Nulls: %08x ",
ADR(args));
WriteString(s); WriteLn;
args[0]:=SHORT(SHIFT(7777777D, -16));
args[1]:=SHORT( 7777777D);
args[2]:=1001;
args[3]:=1002;
RawDoFmt(s, "Dec Long: %8ld Dec Short: %5d Dec Leading Nulls: %08d ",
ADR(args));
WriteString(s); WriteLn; WriteLn;
st:="This is a test";
args[0]:=SHORT(SHIFT(ADR(st), -16));
args[1]:=SHORT(ADR(st));
RawDoFmt(s, "string left adj >%-30s< ", ADR(args));
WriteString(s); WriteLn;
RawDoFmt(s, "string right adj >%30s< ", ADR(args));
WriteString(s); WriteLn;
RawDoFmt(s, "string as it is >%s< ", ADR(args));
WriteString(s); WriteLn; WriteLn;
END RawDoFmtTest.
--
claudio@ethz.uucp
(* ---------------------------------------------------------------------
Disclaimer: I'm not working for ETH-Zurich!
I'm just a student of computer science.
--------------------------------------------------------------------- *)dillon@PAVEPAWS.BERKELEY.EDU (Matt Dillon) (07/08/86)
Thank you, Claudio, for your experimenting in finding precisly what RawDoFmt does. ---- Now, I think I've found a rather strange bug in the ram: drive. If you: (A) open a new file on the ram: drive, then write out, say, 20K one byte at a time. For some reason, the amount of RAM taken up by this file is huge.. on the order of 90K. The DIR shows the file to be the correct size, and you can TYPE it fine.... now, if you CP the file to a floppy, DEL it on ram:, then copy it back (from the floppy to the ram drive), it takes up only as much as it should. It would seem that the amount you write out at a time effects how much actual RAM is used. The larger the block size, the less the amount of RAM used. The smaller the block size (I wrote it out 1 byte at a time), the more RAM is used. Can anybody shed some light on this? I'm currently putting together a small C program to illustrate this (and will, of course, send it to amiga!bugs) using 1.2 B II -Matt