Between this:
so is RTL (string and memory) managers since many things depend on them as core feature.
... and this:
He already got 16K for empty project, that's as expected for the default RTL (correctly stripped and smartlinked)
I'd be VERY interested in knowing what it's doing that TP/BP7's 2k of overhead isn't... Though if that's smartlinking, I'm the Pope. I don't call ASSIGN, why is ASSIGN being linked? I don't call POS, why is POS linked?
If 16k is the expected AFTER smart linking without a single UNIT declaration, just drop the pretense of offering SMALL and TINY targets.
As to:
which you seem too lazy to do in Pascal and I don't understand if you're not lazy to do that in C.
I already have one, mostly written in assembler using NASM... since my ONLY disk interaction is:
BITS 16
CPU 8086
%include "TURBOPAS.MAC"
segment CONST
scoreFile:
db 'PAKUHIGH.SCR', 0
segment CODE
extern highScores, highScoreSize
; function scoreRead:word;
pProcNoArgs scoreRead
mov ax, 0x3D00 ; open file read only
mov bh, 0x3F ; next operation
jmp readWrite
; function scoreWrite:word;
pProcNoArgs scoreWrite
mov ah, 0x3C ; create file
mov bh, 0x40
mov cx, 0x0020 ; Set archive bit only
jmp readWrite
readWrite:
mov dx, scoreFile
int 0x21
jc .done
xchg ax, bx ; moves file handle into AX and operation into BH
mov cx, [highScoreSize]
mov dx, highScores
int 0x21
jc .done
mov ah, 0x3E ; close file
int 0x21
jc .done
xor ax, ax
.done:
retf
It's a game where I only care about the most recent key-down.
segment CODE
gameKeyData db 0
oldISR9 dd 0x00000000
gameKeyInt9h:
push ax
in al, 0x60
xor al, 0x80
jns .done ; ignore key releases
mov [cs : gameKeyData], al
.done:
in al, 0x61
or al, 0x80
out 0x61, al
mov al, 0x20
out 0x20, al
pop ax
iret
... and being a game, I'm doing 99.99% of my video access direct to video memory. What little text handling I have for maximum compatibility is being routed through int 0x21 function 0x02 since TP7's write bombs on DOS 2.x (and since Jr / T1K is my target...) Hence:
; procedure echo(str:string);
pProcArgs echo
push ds
lds si, [bp + 6]
xor ch, ch
lodsb
mov cl, al
mov ah, 0x02
.loop:
lodsb
mov dl, al
int 0x21
loop .loop
pop ds
pRet 4
For those curious about my macros...
; handy macros for creating Turbo Pascal compatible ASM
%macro pProcArgs 1
global %1
%1:
push bp
mov bp, sp
%endmacro
%macro pRet 1
pop bp
retf %1
%endmacro
%macro pProcNoArgs 1
global %1
%1:
%endmacro
If found the default ones that came with NASM a bit inefficient since I'm TRYING to keep my total memory footprint under 64k... Hence my distinguishing between having arguments and not having arguments, since then I can skip screwing with BP. What peaked my interest in FPC for this project (I use it a lot for 32 and 64 bit targets) is that it can make a COM file under TINY... but when it's adding 14k of overhead vs. TP7 for Christmas only knows what really guts that as an option.
Lands sake, yer bloody RTL AFTER smart linking is bigger than DOS 2.11's memory footprint!
I mean of the RTL functions that are programmer-facing, the only ones I am likely using is paramstr, paramcount and abs.... and I can likely replace those if I need to.
I'd be VERY interested in writing my own replacement to the RTL for the 16 bit target -- I suspect a LOT of the problem is just blindly recycling the existing codebase meant for 32 bit including a lot of things (like 64 bit values) that just shouldn't even be tried on the 16 bit platform.
Problem is trying to wade through the endless mess of includes, poor commenting, and "don't tug on that" codebase that is the system unit (No offense guys, but damn...) is making that a bit difficult. There's so much pointless and obvious commenting
(though not as bad as some stuff I've seen in the HTML world -- ever see people do <!-- start header --><header>? HERPA-FREAKING-DERP...)But for now, can anyone at least TRY and point me the right direction of BS'ing the startup to the point I get a heapless small stack build? I'm lost as hell trying to make sense out of the RTL source for the MSDOS tree since it's all over the blasted place. I'd be half tempted to call it spaghetti coding.
Even just a example that gets me as far as a clean compile of "program demo; begin end." with zero RTL stuff would be a huge start as despite some attempts, I'm not even getting that far. Right now I'm being told:
test.pp(2,6) Fatal: Unknown compilerproc "fpc_initializeunits". Check if you use the correct run time library.
Which would be great, if I could find fpc_initializeunits ANYWHERE in the entire RTL source tree to give me an idea what that should even be doing...
Though since I may be skipping units altogether for a TINY build, perhaps I should just bullshit with a empty proc? External to a ret to skip the BP overhead? Does FPC even do a no parameters check?BTW Leledumbo, nice attitude; I rarely come across anyone as brusque as I am.