Lazarus

Programming => Operating Systems => Other => Topic started by: deathshadow on July 22, 2016, 01:09:25 am

Title: DOS linked .obj file calling conventions
Post by: deathshadow on July 22, 2016, 01:09:25 am
In 16 bit operation for DOS, does FPC fallow TP's 6 byte stack offset and order for passing data? The documentation for DOS operation seems a bit "shallow" as yet...

Also, would the memory models where you're limited to 64k of code (TINY, SMALL, COMPACT) use a 4 byte offset? Since everything is near, are linked ASM still far calls?

I'd like to know for sure before I go blindly trying to link some code I've assembled with NASM given how... unpredictable the results can be. (though I guess I could always compile, link, then disassemble to see what it's doing)

The current entry/exit I'm using for TP7 is:
Code: [Select]
push  bp
mov   bp, sp
; passed parameters RTL starting at [BP+6]
pop  bp
retf #
; replace # above with total passed parameter size in bytes, rounded up to nearest 16 bits.

I'd like to move a current project to FPC 3 just to see how it stacks up to TP7, but there's a LOT of linked in ASM in there... I guess temporarily I could switch that stuff back to inline assembler, but that just increases the workload and I kind-of prefer keeping that stuff separate.

I would think using SMALL (which seems best suited to what I'm working on, can't QUITE squeeze it in under 64k) that would be BP+4 (copy of BP I just pushed, near return address) and a regular "ret", right?

Just looking for confirmation on that before I go whole hog.

Curious to see with the RTL out of the way (since I use none of it) how it REALLY compares. Hell, I don't even use write()... you'd almost thing I was working in the undocumented 160x100 16 color CGA mode or something...
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 22, 2016, 01:52:03 am
Another question, any way to stop it from linking in the entire joe-blasted system RTL? I really don't need or want it and it's not like I'm saying "unit system".

Seems a bit herpaderp the compiler doesn't even filter out all the garbage from the RTL you aren't actually calling... isn't that kind of a basic thing even TP3 managed?
Title: Re: DOS linked .obj file calling conventions
Post by: Leledumbo on July 22, 2016, 06:22:06 am
Another question, any way to stop it from linking in the entire joe-blasted system RTL? I really don't need or want it and it's not like I'm saying "unit system".

Seems a bit herpaderp the compiler doesn't even filter out all the garbage from the RTL you aren't actually calling... isn't that kind of a basic thing even TP3 managed?
Create your own, but keep in mind you will lose a lot of features that's RTL managed. There's really no documentation or guide to do this, you can start from rtl/dos folder. I forgot which asm is used for startup, but you should be able to have a very short asm startup file + unit system containing only HRESULT type identifier (of whatever type you want). I did this when I want to make a bootloader for my OS, which fits the limit of 512 bytes stage1 bootloader (was around 300-400 bytes). It's overkill, though. Better use it to create stage2 bootloader as stage1 is actually already very simple in asm (since its main job is to load stage2).
Title: Re: DOS linked .obj file calling conventions
Post by: Thaddy on July 22, 2016, 12:26:18 pm
I forgot which asm is used for startup
Nasm... and  Open Watcom linker and tools. See the wiki: http://wiki.lazarus.freepascal.org/DOS.
Title: Re: DOS linked .obj file calling conventions
Post by: marcov on July 22, 2016, 01:17:07 pm
Why don't you simply look at the code generated by FPC with -a or so?
Title: Re: DOS linked .obj file calling conventions
Post by: Thaddy on July 22, 2016, 01:43:43 pm
Why don't you simply look at the code generated by FPC with -a or so?
Mmmwah, yes I forgot: the only dependency is recently only nasm  because the internal linker is implemented for the platform.
In trunk there is no need for the Watcom tooling.

I stand corrected. But the wiki needs an update in this case...
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 23, 2016, 01:12:36 am
Laughably I switched to NASM in anticipation of this about a year ago, then promptly shelved the project due to health concerns...

I was kind of hoping to get the total project back under 64k (my target is DOS 2.0 on a unexpanded PCJr....) and squeeze a bit more speed out of it by swapping everything to near calls -- something TINY would let me do... but that 16k minimum size from the start tosses 14k on a project that really doesn't need 90%+ of the stuff built into SYSTEM.

It does make me wonder though, does FPC even HAVE smart linking? Or is the linker so dumb it just blindly includes everything "used or not"? One of TP's biggest features from the earliest of releases was that procedures, functions, types, and so forth were not just blindly included -- ESPECIALLY if it was coming from a Unit.

Is FPC not smart linking, or is the system unit just that bloated a mess once you're down in the 16 bit platform?

Ah well, back to TP7... Was kind of hoping for a 32 bit compiler so I could build completely from modern (since NASM is slow as **** under DOSBOX) and TPC32 drops the ball if you dare to state less than 8k of stack or no heap. Amazingly, what I'm working on only needs 2k of stack...

Back to plan B, rewriting all my units as includes so everything can be near calls... JUST to try and squeeze that last drop of blood from the stone known as the PCJr.

Wasn't there a Delphi flavor that was a 32 bit compiler but could still compile 16 bit DOS .exe from the command line?

I HATE to say it, but I'm half tempted to move the project to C... and I HATE C... it's just 99% of the time if you want the compiler to do something you can tell it to do it easy-peasy...

Like omitting stdio.h
Title: Re: DOS linked .obj file calling conventions
Post by: Cyrax on July 23, 2016, 01:23:12 am
You need to build whole RTL with smartlinking enabled. If I recall correct, this should be enabled by default.
Title: Re: DOS linked .obj file calling conventions
Post by: Leledumbo on July 23, 2016, 04:11:37 am
I forgot which asm is used for startup
Nasm... and  Open Watcom linker and tools. See the wiki: http://wiki.lazarus.freepascal.org/DOS.
The startup file, not the assembler.
Title: Re: DOS linked .obj file calling conventions
Post by: Leledumbo on July 23, 2016, 04:30:25 am
It does make me wonder though, does FPC even HAVE smart linking? Or is the linker so dumb it just blindly includes everything "used or not"? One of TP's biggest features from the earliest of releases was that procedures, functions, types, and so forth were not just blindly included -- ESPECIALLY if it was coming from a Unit.

Is FPC not smart linking, or is the system unit just that bloated a mess once you're down in the 16 bit platform?
It does, if you activate it, and it's done from compiler side, regardless your stupid linker, with limitations where initialization and finalization sections are not removed since there's no way to prove that they're not used, so is RTL (string and memory) managers since many things depend on them as core feature.
I HATE to say it, but I'm half tempted to move the project to C... and I HATE C... it's just 99% of the time if you want the compiler to do something you can tell it to do it easy-peasy...

Like omitting stdio.h
Go ahead, no one will stop you. You will need to write your own RTL anyway, which you seem too lazy to do in Pascal and I don't understand if you're not lazy to do that in C.
You need to build whole RTL with smartlinking enabled. If I recall correct, this should be enabled by default.
He already got 16K for empty project, that's as expected for the default RTL (correctly stripped and smartlinked) since it's fully featured, but he couldn't accept it.
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 23, 2016, 09:34:59 pm
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:

Code: [Select]
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.

Code: [Select]
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:
Code: [Select]
; 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...

Code: [Select]
; 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.
Title: Re: DOS linked .obj file calling conventions
Post by: marcov on July 23, 2016, 10:20:27 pm
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,

Allowing for things to be overriden that are hardcoded in TP7 because it is an ancient obsolete thing from 1990. Things like localisation, unicode etc can be plugged in, and this works in dos too.

The default RTL is mostly unified over all targets, and while ports (like 16-bit msdos) can skip some parts, the choices are more made from a maintenance viewpoint.

Quote
I'm the Pope. I don't call ASSIGN, why is ASSIGN being linked? I don't call POS, why is POS linked?

Your Holiness, stdin and stdout are opened on startup (assign) and commandlines are parsed into parameters. ( what probably explains pos?). Things like this can be learned from the RTL sources in mere minutes.

Quote
If 16k is the expected AFTER smart linking without a single UNIT declaration, just drop the pretense of offering SMALL and TINY targets.

This is nonsense. Most people obsessing with binary sizes will maintain their own RTLs in the end. Such targets are specialist domains nowadays.  And cutting things to customize an RTL is easier than make your own (+compiler)

But for development and, more importantly testing it, there must be an RTL, and it must support many features that "big" FPC does, so that it can be tested. Even if most of the users will cut and keep only the parts they are interested in. At least for the lower memory models.
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 23, 2016, 11:02:40 pm
stdin and stdout are opened on startup (assign) and commandlines are parsed into parameters.
... and what the *** is it using func... wait, nevermind. Soft-coded to be cross-platform compatible off one codebase. Something that one would generally NOT do if you were optimizing for a specific platform and why the RTL is a bloated mess on x86 DOS. Laugh being the overhead of the function on POS and what it returns likely being more code than if you just hardcoded it in ASM... but again there's likely little to nothing in the RTL hardcoded in ASM thanks to the cross-platform nature.

... though I'm seeing enough inline assembler I'm still wondering where the overhead is coming from -- probably the unicode stuff which for a tiny or small I wouldn't waste the overhead on, but I could see the use on a larger memory platform; might even come in handy later.

I think for the project I'm working on, FPC is just the wrong tool for the job. ESPECIALLY if what I want to do -- actually build a clean minimalist system.pp with jack in it just to BS the compiler into working is undocumented.

Back to TP7 and removing all units for includes to get rid of the far call overhead... Sadly that means a lot of my external ASM is going back into inline ASM, but it will probably still pay off better in the long run for my overall objective... though some of it really needs to remain external thanks to the lack of macro's in the inline assembler... unless I REALLY want to unroll sections that read:

Code: [Select]
charH_e:
char_X.X.
char_X.X.
char_XXX.
char_X.X.
char_X.X.
charEnd 4, 4

charH_o:
char_.X.X
char_.X.X
char_.XXX
char_.X.X
char_.X.X
charEnd 4, 4

As I'm using coded sprites... probably NOT worth the effort. Besides, a string write might be a far call, but internal calls to the characters would be near anyways. likely not worth my time or any savings to try and get around that.

for the morbidly curious:
Code: [Select]
%define char_.X.X   charLine ah, ah

Code: [Select]
%macro charLine 1-3
mov   [si + tgCharIndex], %1
%ifid %2
mov   [si + tgCharIndex + 2], %2
%ifid %3
mov   [si + tgCharIndex + 4], %3
%endif
%endif
%assign tgCharIndex tgCharIndex+160
%endMacro

Code: [Select]
%macro charEnd 2
%assign tgCharIndex 0
%assign tgNextIndex %2
add  bp, %1
ret
%endMacro

The charend parameters exist as this is a kerned font... variable width since, well... when working at 160x100 you need all the space you can get... most characters being only 3px wide, but some like M and W obviously needing another byte (aka two pixels) or write, and possibly two bytes of offset to the next cursor position. ... and yes, this **** is unrolled for a reason, it's called speed.

Be funny to dial back to TP3 just to make it a COM file and see the results... I am surprised how many pascal compilers seem to go tits up  if you try to say you don't want/need the heap.

Kind of strange... I can hand assemble my own Z80 machine language, was writing Pascal when there was UCSD and.. uhm, well... there was UCSD.... but I look at the entire rtl/msdos and rtl/inc directories for FPC with a blank dumbfounded stare.

Getting too old for this ****!

Pascal is still my favorite language, but it's always felt hobbled by the compilers and interpreters when it comes to doing the types of things I do. TP/BP7 is still the pinnacle for DOS, and FPC IMHO is the pinnacle for 32 and 64 bit win/lin (sorry EmbacardaWhateverThe***TheyreCalled), and xCode's implementation beats out FPC on OSX (at least THEN I can get OpenGL on SDL working)... but you really still can't seem to vary from that a whole lot.

REALLY wish out-of-box FPC was "ready' across all platforms so I'm not constantly switching between compilers and/or development environments... or re-inventing the wheel when it comes to having it NOT do things.

I mean all I want is stack management and dick else... I can handle the rest and I can't even get that far... is that so hard that it's not even documented and NOBODY can actually respond with a working example?
Title: Re: DOS linked .obj file calling conventions
Post by: marcov on July 23, 2016, 11:48:57 pm
REALLY wish out-of-box FPC was "ready' across all platforms so I'm not constantly switching between compilers and/or development environments... or re-inventing the wheel when it comes to having it NOT do things.

I really wonder why you think you can desire to generate code for odd ball targets that are 30+ years out of date without any effort invested from your side.

This is not 1990, and this is not TP which was a projecta tenth of the size, but had a thousand times more users or more, and paying ones. FPC/8086 is done by one person in his spare time as a work of love.

Quote
I mean all I want is stack management and dick else... I can handle the rest and I can't even get that far... is that so hard that it's not even documented and NOBODY can actually respond with a working example?

You have a working system in source which compiles to a grand total of (by your own count) 16kb.  The startup assembler gives you the name of the entrypoint (so you don't even have to have dos knowledge to figure that out), you seem to have a symbol list of what ends up in the binary, how hard can it be to figure it out?   

You are not asking for support for people but to do the hard work for your specific circumstances for you.

If it is really important and way above your head you can always hire somebody who knows what he is doing.

Title: Re: DOS linked .obj file calling conventions
Post by: Leledumbo on July 23, 2016, 11:59:55 pm
@deathshadow:
Contact Nikolay Nikolov as the one and only maintainer of the i8086-msdos port and HIRE him properly to help you creating your very-own-specialized-super-duper-minimized-for-your-game-needs-only RTL. Most of us doing games in Windows, Linux and OS X, not 30++ years old DOS. And that requires the whole RTL capability + other packages and libraries, which your dream RTL won't quite cut.
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 24, 2016, 10:37:43 am
Seems more like I should contact the AVR guy(s), they seem to have figured it out.
Title: Re: DOS linked .obj file calling conventions
Post by: marcov on July 25, 2016, 11:48:40 am
Seems more like I should contact the AVR guy(s), they seem to have figured it out.

I wasn't aware they had PCJr ports ?
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on July 25, 2016, 12:27:24 pm
I wasn't aware they had PCJr ports ?
I was referring to the fact that with the average 32 bit AVR chip coming in at 16k of flash, a 16 bit RTL wouldn't leave you any space for your own code, so they quite obviously are adept at leaving out all the extras that really don't apply to the platform.

... and that's really the issue I'm having -- for TINY and SMALL, all those bells and whistles don't leave you with enough space for your own code, and much of it is pretty pointless since what good is, well... take unicode support for example... you can't show it in text mode and even with a 8x8 font you wouldn't have the RAM to render it in graphics mode either. There's zero point in even having it in there.

... or that it seems to parse paramstr and store it whether you are using it or not -- something you generally wouldn't do on a DOS target you'd parse it in realtime.

... and I'm willing to put in the work for this, I just can't make sense of where to even start as the existing RTL is a massive codebase and everything I tug on just breaks it.

Again, a little surprised so much is hardcoded into it baseline instead of being truly optional -- and that so much of it is cross-reliant... and that the common /inc/system.pp version isn't more barebones with just prototypes and requirements. Again, someplace a proper .h file C style would be far more useful.

You know, all the facing and required procedures, constants and variables actually documented in one place in one file instead of spread out over what appears to be 80 separate files for Christmas only knows what?

Again why I feel like I'm looking at '70's style spaghetti. Hey Anthony... (https://www.youtube.com/watch?v=KlNAYCcxgUw)

Though playing with it has helped me on the TP7 front as it got me thinking about the near/far difference, making me swing an axe at using units altogether freeing up ~4k or so of memory and netting a 5% speed boost in the process. To simulate unit begin:end. I'm just using a similar model to exitproc... kinda.

Units suck for small memory footprint... makes sense since each one gets its own code segment. Also seems like TP's units have a pretty big stack overhead as I'm now down to only needing 1k of stack. I like that.

... and it now fits to build in FPC's TINY as a COM file, but it's right against the wall and I've got another ~8k of code+data (once compiled)  to add to it by the time it is done. Still lets me compare it speed wise. NOT too surprised FPC is slower since it REALLY wasn't designed for 16 bit targets in the first place, but it is promising to at least see support however much still needs to be done to make it useful on said platform.

Also got me digging into TP's RTL since the BP7 CD has the source on it. Removing all the pointless constants like the idiotic SEGB800 (that I NEVER understood the point of, why not just type $B800? It's not like a remote mem reference is going to be better than an immediate, even on the inefficient 8088) or the overlay stuff... the constants/variables for which are included whether the functions that use them are loaded or not.

There's a lot of stuff in FPC and TP's RTL that to me feels like the writer seemed to think that constants behave like macros instead of going into the data segment/selector. But that's like how TP/BP/Delphi/FPC "constants" aren't "constants" since they're writable. They're just global scope variables with predefined values... shocking how many people writing Pascal don't know that. ... and why even having the distinction from old-school Pascal is pretty pointless by modern coding standards.

Especially since x86 16 bit is still common in the microcontroller world... though it's been nice to have ARM slowly muscle it's way in there ... particularly the Cortex M4 on SoC's like the Freescale Mk20DX's.

Would love to someday be able to use FPC on a Teensy 3.x development board and kick WinAVR to the curb for my MIDI wind controller project.

Of course that understanding of what a const is becomes painfully obvious to 8088 development, where the mantra of "use constants a lot. NO, a LOT!!!" is actually the antithesis of speed optimization despite the improved code legibility... one of those times where Pascal could REALLY use a PROPER equivalent to C's "define".
Title: Re: DOS linked .obj file calling conventions
Post by: Thaddy on July 25, 2016, 12:41:59 pm
Well then.
Topic started about msdos: fully supported and within Bill Gates memory limits. .com, .exe, several memory models like in the olden days ;)
But what you really seem to mean is a kind of  embedded version for 8086/8088.
Leledumbo explained one way on how to do that because he did that himself.
Then you switch over to AVR... totally different, but again: FPC embedded is available for AVR...

So apart from your cocky language... did you really investigate the options ;) Guessed not.
Title: Re: DOS linked .obj file calling conventions
Post by: Leledumbo on July 25, 2016, 01:55:23 pm
It's no way difficult to write your own RTL and drops any functionality you don't need. Judging from your coding level (well, not many code assembly fluently), you're just too lazy to understand the architecture (which you don't really need to) while your skills should be more than adequate.
Would love to someday be able to use FPC on a Teensy 3.x development board and kick WinAVR to the curb for my MIDI wind controller project.
Paul seems to have done it last year: http://forum.lazarus-ide.org/index.php/topic,28561.0.html
I feel like agreeing Thaddy's comment:
So apart from your cocky language... did you really investigate the options ;) Guessed not.
Title: Re: DOS linked .obj file calling conventions
Post by: engkin on July 25, 2016, 04:01:03 pm
I am going to leave this link (http://forum.lazarus.freepascal.org/index.php/topic,25084.msg151877.html#msg151877) here.
Title: Re: DOS linked .obj file calling conventions
Post by: marcov on July 28, 2016, 11:50:09 pm
I wasn't aware they had PCJr ports ?
I was referring to the fact that with the average 32 bit AVR chip coming in at 16k of flash, a 16 bit RTL wouldn't leave you any space for your own code, so they quite obviously are adept at leaving out all the extras that really don't apply to the platform.

You are comparing a general product to a highly specialized one. The general ones can come close, but need per case tweaking.

As said the FPC current distribution is optimized for easy testing and so that all units work as much as possible. It is not cut down to your exact expectations of a minimal RTL.

Again: Cut down/customize the msdos one for your purposes, or create a new one based on the minimal skeletal "embedded" rtl. But I think cutting down the msdos one is easier.

Quote
... and I'm willing to put in the work for this, I just can't make sense of where to even start as the existing RTL is a massive codebase and everything I tug on just breaks it.

Dozens of people manage to on a daily basis. Try harder.

Quote
Again, someplace a proper .h file C style would be far more useful.

No it wouldn't be. We don't have an unit system for nothing.

Quote
You know, all the facing and required procedures, constants and variables actually documented in one place in one file instead of spread out over what appears to be 80 separate files for Christmas only knows what?

.h style would be even more files.

Quote
Again why I feel like I'm looking at '70's style spaghetti. Hey Anthony... (https://www.youtube.com/watch?v=KlNAYCcxgUw)

Less playing/youtubing, more coding.

Quote
... and it now fits to build in FPC's TINY as a COM file, but it's right against the wall and I've got another ~8k of code+data (once compiled)  to add to it by the time it is done. Still lets me compare it speed wise. NOT too surprised FPC is slower since it REALLY wasn't designed for 16 bit targets in the first place, but it is promising to at least see support however much still needs to be done to make it useful on said platform.

Well, it is good that you managed to make a step. What optimization settings did you use?

Quote
Also got me digging into TP's RTL since the BP7 CD has the source on it. Removing all the pointless constants like the idiotic SEGB800 (that I NEVER understood the point of, why not just type $B800? It's not like a remote mem reference is going to be better than an immediate, even on the inefficient 8088) or the overlay stuff... the constants/variables for which are included whether the functions that use them are loaded or not.

No, true constants are not loaded in the binary. Only typed constants are. (also in TP)

Constants are used to make code that uses such constants switch between real mode and 286 protected mode.

Quote
There's a lot of stuff in FPC and TP's RTL that to me feels like the writer seemed to think that constants behave like macros instead of going into the data segment/selector. But that's like how TP/BP/Delphi/FPC "constants" aren't "constants" since they're writable. They're just global scope variables with predefined values... shocking how many people writing Pascal don't know that.

There are constants ( x = 10) and typed constants ( x: integer =10). There is a difference.

Quote
Especially since x86 16 bit is still common in the microcontroller world... though it's been nice to have

Which x86 systems are nowadays really targeted at 16-bits development ? (as opposed to 32/64bit ones that can still just boot 16-bit?)

Quote
Of course that understanding of what a const is becomes painfully obvious to 8088 development, where the mantra of "use constants a lot. NO, a LOT!!!" is actually the antithesis of speed optimization despite the improved code legibility... one of those times where Pascal could REALLY use a PROPER equivalent to C's "define".

No, it shouldn't. You are mixing things up.
Title: Re: DOS linked .obj file calling conventions
Post by: deathshadow on August 04, 2016, 07:46:28 am
Again: Cut down/customize the msdos one for your purposes,
Which I'm willing to try to do if I can make sense of this convoluted mess.

or create a new one based on the minimal skeletal "embedded" rtl.
Which I'm willing to do to an extent, but I'm noticing even that has more crud in it than I want... Though I think much of that is just the generic nature of the beast overall.

What I'm really looking for is a sub 2k single file .pp that just BS's it into compiling. Just list out what HAS to be included/set in a device neutral manner... I'm starting to suspect that unlike C compilers, FPC just isn't set up internally to be THAT generic/vanilla an implementation of Pascal.

But I think cutting down the msdos one is easier.
Not from what I'm seeing, it's spanning so many separate files and pulling such massive amounts of the "generic" cross platform codebase, everything I "tug on" just breaks it.

Dozens of people manage to on a daily basis. Try harder.
Can you point me on examples of this? How are they figuring this out? If dozens of people are "doing this daily" then WHERE ARE THEY? That reeks of pulling a number out of one's backside.

.h style would be even more files.
Done properly it would be ONE master file giving you ALL the prototypes for the SINGLE library. Admittedly, a concept that a LOT of people seem to find alien these days. (could be worse, could be full stack JS)

It's called an INTERFACE file for a reason.

Well, it is good that you managed to make a step. What optimization settings did you use?
Forget right now, but I'm rejecting FPC for now as it's too much hassle since I've already lost two years to my health, I don't want to waste a year screwing with the tools.

Actually looks like I'm moving to Open Watcom C since it does what I want done out of the box (well, other than the fact that it is C). Compiles to 16 bit TINY from 32/64 bit command line, smallest .COM of any higher level language I've tested, etc, etc... Even so I'm gonna keep playing with FPC as I PREFER Pascal to C, it's just the state of compilers keeps making the choice for me.

Had a LOT of people trying to point me at Microsoft C++ 8.0's command line compiler, that's good for a laugh as it makes FPC's implementation shine by comparison. (Gee, inefficient compilers from Microsoft? SAY NOT SO!!!) and still fails to meet my actual goal of something I can call from a Windows command line under Win 8.1 to compile to 16 bit. (since compiling inside DOSBOX sucks, even at max cycles)

Admittedly the guys who keep pointing me at MASM and Microsoft C are all ex big-iron guys, so they come from a whole different world than those of us who started out in the microcomputer era on things like the ELF and Trash-80. Laughably, they fit in better with today's "Oh just throw more code and hardware at the problem" mentality.

No, true constants are not loaded in the binary. Only typed constants are. (also in TP)

I should have specified, my bad:

Code: [Select]
  Seg0040: Word = $0040; { Selector for segment $0040 }
  SegA000: Word = $A000; { Selector for segment $A000 }
  SegB000: Word = $B000; { Selector for segment $B000 }
  SegB800: Word = $B800; { Selector for segment $B800 }

That's right off the Borland Pascal 7 CD. THOUGH I had someone explain to me WHY they do that!

Code: [Select]
mov  es, [Seg0040] ; 8 + EA, 3 bytes if DS reference
3 fetch (BIU empty) * 4 + 8 exec + 9 ea + 2 bytes data * 4 = 37

With fetch, mem, and EA calculated that's a worst case of 37 clock cycles BIU empty on a 8088, in 3 bytes.

That is less code, and doesn't need a extra register compared to:

Code: [Select]
mov  ax, 0x0040 ; 4 clocks, 3 bytes
mov  es, ax ; 2 clocks, 2 bytes
3 fetch * 4 + 4 exec + (2 fetch * 4 - 4 BIU free) + 2 = 22

22 clocks but 5 bytes and you need a register free to do it.

So if that is used ONCE, you break even. More than once you save two bytes and no need for getting an extra register involved... but it costs you 15 clock cycles to do it.

Since you cannot actually do:

Code: [Select]
mov  es, 0x0040 ; this will not assemble!

Since there is no such thing as "mov segreg, immed" -- just mem#e and reg#e :(

Which x86 systems are nowadays really targeted at 16-bits development ? (as opposed to 32/64bit ones that can still just boot 16-bit?)
VERY popular to do with Intel Quark D series -- While they are 32 bit x86 code compatibile, NOBODY runs them in 32 bit protected mode. This is becuase the overhead of the virtual page-space ALONE would be murder when on the low end (D1000) you have 32k of instruction RAM and 8k of SRAM, and at the high end (SE) we're talking 384k of instruction space and 80k of RAM. You might use the 32 bit math and memory copy capabilities, but when you only have a total combined address space on the primary models of 52k or less, you're not building as anything but TINY (so you can keep all your segments the same). Even with the SE, you're hard pressed to find a legitimate reason NOT to run it in "REAL" mode since that tops out at 436k total combined address space. The ideal on that larger address space most likely being COMPACT -- aka CS, DS, and SS all getting their own 64k limit, with the rest as a heap. Maybe LARGE by allowing functions to be FAR if needed with thier own CS, but really if you're that lean on RAM it's unlikely you'd want the those extra 8-16 bytes of overhead added to every function call in the code much less 2 more bytes on the stack.

(hell, that's part of what made me start down this path in the first place, reducing function call overhead!)

You only tread into high end specs when you get into the SOC's like the Quark X1000 with it's 400mhz clock and external DRAM capabilities. I've seen dev boards for that ranging from 256 megs all the way up to 2 gigs.

There are also a LOT of embedded systems that still run DOS... on real 80186/lower PDIP chips. You'll find them in the same type of environments you'll still find 8052's chugging along. Changes in the mechanical engineering of the robots or other machines they are controlling means they still need people to write new code for them -- PARTICULARLY since many modern chips don't want to let you get that far into the low-end I/O, and convincing them to move to AVR or ARM presents them with an unknown.

Though it's funny how even a 16mhz ATMEGA32 kicks a 25mhz 386DX's backside on raw computing power... But try convincing people with million dollar machines they've been using for 40 years to switch to the same chip that's in a Arduino Micro. What's wrong with the existing one?!? *SIGH*

No, it shouldn't. You are mixing things up.
Again, my bad, I should have been more specific -- people seem to treat ALL constants that way. That it's so easy to mess it up is why the distinction of "typed" vs. "untyped" is not just confusing, it's annoying... and poorly documented! Having a different name for them to explicity say "Don't do that" would REALLY help with language clarity... and here I thought language clarity was one of Pascal's strengths and goals.

But again, the implementation often differs from the original ideals.

Side note, DAMN I hate C... not even one include into porting this over and I'm already cursing at how silly a language it is. STILL not convinced this is a joke:
https://www.gnu.org/fun/jokes/unix-hoax.html

As it is I've set up the "new" C99 integer types just for code clarity sake... Whoever thought "char" should be a signed 8 bit integer needs a good swift kick in the groin... but then I don't think I've EVER written anything that wasn't for a 8 bit processor that used a 8 bit signed integer.
TinyPortal © 2005-2018