Issues in real DOS on a 486

[Ham62]

Recently I tried setting up FreeBASIC on my 486 and found a few problems with FB that should probably be fixed in an update. Firstly, after FB compiles the project and writes the ldopt.tmp file to pass to LD.EXE it throws an error saying it cannot find the file “c:\\fbc\\bin\\dos\\i386go32.x”. For some reason in the latest version for DOS it adds the double \\ when writing the file that MS-DOS doesn’t understand.

Secondly, I found out that FreeBASIC doesn’t work unless you have a FPU. On a CPU without a FPU like any SX processor it just crashes when it loads because it attempts to reset the FPU, which isn’t present on the system.

I found the way to get around it is to install the DJGPP FPU emulator so that FB programs don’t run into this issue when it loads: http://www.delorie.com/djgpp/dl/ofc/cur ... emu21b.zip
It should probably be documented somewhere so that people with SX processors know that FB expects the emulator to be there for it to run.

I’d also like to note that the FBC compiler is painfully slow. I have a UMC Green CPU 486 at 33MHz with 4MB RAM and I timed it to see how long it would take to compile a single line program: PRINT “Hello World!”. At the full 33MHz with turbo on it took about 25 seconds for FBC to finish, 8 seconds for AS.EXE and 98 seconds for LD.EXE. With turbo off however it drops the CPU frequency to about 8MHz and I compiled the same program again and timed it. At 8MHz it took FBC 40 seconds, AS.EXE 13 seconds and LD.EXE 150 seconds to finish. The main issue with speed is how much RAM all of the build tools use already on their own.

When you start building the application before FBC calls AS.EXE it is already using ~5MB RAM which is quite a lot for a DOS compiler. However, after FBC and AS.EXE finish their stuff and FBC loads LD.EXE. LD uses about 6MB of RAM on it’s own and that means if you just run FBC.EXE and don’t compile each step on it’s own then it’s using up 11MB of high memory. In my case I only have 4MB of memory so it is using a LOT of swap memory on the HDD which is extremely slow.

I feel that these issues should be addressed by the next update because they are pretty big issues and caused lots of problems for me when setting it up.

[marcov]

These are mostly wellknown issues, except for the escaping which is probably a binutils versioning issue. (newer allow it, old dos ones not)

The FPU issue is in the documentation, the requirements part:

You need a 80386 or newer CPU and cca 4 MiB of RAM. For compiling of large programs or libraries, you will need more. Similar applies to executables generated by FBC, those using FB's graphics library however will need a better/faster CPU (200 MHz (?), work in progress, code not yet fully optimized, and exact minimum not known by now). FBC and executables generated by it need an FPU (80387, 80487, always built-in since Pentium). This requirement can by bypassed using "EMU387" (auto-loaded if needed, but not included in FB packages, see delorie.com/djgpp/... ), or by avoiding floats and (non-trivial) removing float-related startup code.

The timings are not worth much without information about your disk cache. (probably not much with 4MB). CWSDPMI or another DPMI provider might be swapping. Personally I think it is a wonder it does anything at all. The question is if you can find anybody willing to waste time on it work on it.

Even if you take the 486 project serious, I think time is better invested in generating better binaries for such target than to work on improving compiling ON that target.

[Dinosaur]

Hi All

Ham62, I have dozens of 486 cpu boards running in Industrial machines doing a great (and Fast) job.

However, I gave up many years ago trying to "develop / compile" on them.
In the very early days, I used a Parallel port linking program to simply transfer the compiled
program to the "Dos" computer as it didn't have a removable disks but had the very earliest of the onboard flash disks."DiskOnChip"

I have also had to use an emulator library to overcome the FPU problem, but I recall using an emu switch on the compile line later on.

Regards

[Ham62]

The FPU issue is in the documentation, the requirements part:
-snip-

Could you please link to where this actually is in the documentation? I looked through the online wiki and readme provided with the compiler but did not see anything about FPUs there. Also I think part of that documentation you quoted is incorrect.

FBC and executables generated by it need an FPU (80387, 80487, always built-in since Pentium). This requirement can by bypassed using "EMU387" (auto-loaded if needed, but not included in FB packages, see delorie.com/djgpp/... ), or by avoiding floats and (non-trivial) removing float-related startup code.

Even if you don't reference to the FPU once in your code, when the executable loads into memory and starts executing, before it gets to the code you've compiled FBC tries to reset the FPU. So it can't really be bypassed by avoiding floats unless there are some switches I don't know of, but even then they should be mentioned in that paragraph so people know to use those when compiling their application.

CWSDPMI or another DPMI provider might be swapping.

CWSDPMI.EXE is only a DOS extender and is only 20KB. FBC is what calls it to do stuff including memory management which is why it is using swap. When FBC calls CWSDPMI to allocate more memory to do something, CWSDPMI sees that there isn't enough physical memory available and then starts using swap so that the program doesn't crash. So while CWSDPMI is what is providing the swap memory to use, FBC is the only thing using that swap memory because it is not optimized well for low memory environments.

Even if you take the 486 project serious, I think time is better invested in generating better binaries for such target than to work on improving compiling ON that target.

I don't agree with this. Saying that you should use newer computers to compile code to run on older systems just because the compiler is not optimized for low memory environments and is very slow is like saying that you should rent a server rack to compile a new Windows application just because the compiler someone made is too slow to run on a lot of Windows PCs.
I'm not saying that the quality of the binaries being created doesn't matter, but the compiler should be able to work reasonably well on the hardware it's compiling for. I'm not expecting FBC to compile very fast on a computer that old but one would expect that a hello world takes less then 3 minutes to compile.

[fxm]

In Requirements, paragraph "DOS version":

• .....
• You need a 80386 or newer CPU and cca 4 MiB of RAM. For compiling of large programs or libraries, you will need more. Similar applies to executables generated by FBC, those using FB's graphics library however will need a better/faster CPU (200 MHz (?), work in progress, code not yet fully optimized, and exact minimum not known by now). FBC and executables generated by it need an FPU (80387, 80487, always built-in since Pentium). This requirement can by bypassed using "EMU387" (auto-loaded if needed, but not included in FB packages, see delorie.com/djgpp/...∞ ), or by avoiding floats and (non-trivial) removing float-related startup code.
  .....

[marcov]

The FPU issue is in the documentation, the requirements part:
-snip-

Could you please link to where this actually is in the documentation?

FXM answered that.

FBC and executables generated by it need an FPU (80387, 80487, always built-in since Pentium). This requirement can by bypassed using "EMU387" (auto-loaded if needed, but not included in FB packages, see delorie.com/djgpp/... ), or by avoiding floats and (non-trivial) removing float-related startup code.

Even if you don't reference to the FPU once in your code, when the executable loads into memory and starts executing, before it gets to the code you've compiled FBC tries to reset the FPU.

Yes. The FPU stack needs to be initialized. FB can't know that you don't plan to use x87, you could have opcodes in externally crafted .o's. (like the C rtl)

CWSDPMI or another DPMI provider might be swapping.

CWSDPMI.EXE is only a DOS extender and is only 20KB. FBC is what calls it to do stuff including memory management which is why it is using swap. When FBC calls CWSDPMI to allocate more memory to do something, CWSDPMI sees that there isn't enough physical memory available and then starts using swap so that the program doesn't crash. So while CWSDPMI is what is providing the swap
memory to use, FBC is the only thing using that swap memory because it is not optimized well for low memory environments.

More or less correct, with that remark I just wanted to point out that the slowliness of the compiler/assembler/linker is a combination of CPU processing power but also memory and disk constraints.

If you go beyond the memory limit and cwsdpmi starts swapping, it is possible that the disk cache has already shrunk to some minimal size too, adding a lot of latency to diskaccess.

Even if you take the 486 project serious, I think time is better invested in generating better binaries for such target than to work on improving compiling ON that target.

I don't agree with this. Saying that you should use newer computers to compile code to run on older systems just because the compiler is not optimized for low memory environments and is very slow is like saying that you should rent a server rack to compile a new Windows application just because the compiler someone made is too slow to run on a lot of Windows PCs.

Why then stop with 486! All software in the world must run on an Intel 4004 in 256 bytes.

I'm not saying that the quality of the binaries being created doesn't matter, but the compiler should be able to work reasonably well on the hardware it's compiling for.

No that is totally ridiculous, and specially for 32-bit compilers that compile for targets that still suffer from 16-bits tradeoffs and are mostly too light to fully run 32-bits OSes.

I'm not expecting FBC to compile very fast on a computer that old but one would expect that a hello world takes less then 3 minutes to compile.

I'm saying your expectations are pretty random.


Anyway, as usual, minimalist discussions lead to nothing. It will be interesting what developer resources you come up with to back your expectations. It is easy to point to a ridiculous target and expect others to do it, it is harder to actually do it.

[MrSwiss]

... need an FPU (80387, 80487*, always built-in since Pentium). <-- this needs correction

Should read: ... always built-in since 80486 (DX Versions only) / Pentium

Explanation:
80486 without any suffix (FPU on die, but not working properly, earliest models), the first CPU/FPU combination by Intel!
80486 SX (later) Versions, did have it on the die (the FPU), but the internal connections where internally cut off by Intel.
The additionally sold 80487 was, in effect a 80486 DX (after Intel fixed the initial FPU problems, on the 80486).

*something that didn't really ever exist (except as an Intel Marketing Gag, see above).

[Tourist Trap]

Recently I tried setting up FreeBASIC on my 486 and found a few problems

Hello,

I'm understanding you work on the 486 real hardware so you may necessarily feel not at ease with software designed to fit the next generation platform. However you possibly have underestimated a factor, you can access for free or almost free, most of the old 486 softwares library that are perfectly optimized for your hardware (low processor/hard disk consumming compared to anything buit more recently). So if I were you I would look for the best softwares from the time of the 486 platform (look at this link for old compilations : http://www.abandonware-magazines.org/af ... 30&page=12).

As a start you could grab QB7.1, and the early visual basic versions. Or as said by Dinosaur, manage to compile on a modern platform and then run on the 486 machine. Sound at least simplier to me.

[jamjamason]

Sounds like you need Powerbasic for DOS.

http://powerbasic.com/products/pbdos/

I used it for twenty years on everything from 386 to Pentium 4. Blazingly fast compilation and tiny executables size.

[D.J.Peters]

Yes PowerBASIC is my first choice for DOS since 1990 also.

Try before buy :-)

A full freeware compiler FirstBASIC (PowerBASIC V2.10 )
pro: creates really fast compiled *.exe
cons: no UDT's, no inline assembler, limited memory, IDE without mouse
download: http://www.powerbasic.com/files/pub/firstbas.zip

A limited version of PowerBASIC V3.20 Trial:
download: http://www.powerbasic.com/files/pub/trypb32.zip

Joshy

[rugxulo]

Hi, I know I'm late, but I had to chime in a bit! :-)

I’d also like to note that the FBC compiler is painfully slow. I have a UMC Green CPU 486 at 33MHz with 4MB RAM and I timed it to see how long it would take to compile a single line program: PRINT “Hello World!”. At the full 33MHz with turbo on it took about 25 seconds for FBC to finish, 8 seconds for AS.EXE and 98 seconds for LD.EXE. The main issue with speed is how much RAM all of the build tools use already on their own.

Unfortunately, FB (and DJGPP and BinUtils) are not optimized for old machines anymore. A 486 with 4 MB is roughly GCC 2.7.2.1 and BinUtils 2.6 or such. Not sure if there is an easy "fix" for FB. Maybe you could downgrade your as + ld to older versions (or perhaps pass --reduce-memory-overheads option), but I doubt that would help much.

Honestly, I think you should use the (bundled with MS-DOS) QBASIC interpreter for rapid development before compiling the final product. Or you should try FreePascal 3.0.0 (which has good string support, something most BASIC fans need), which now has an internal linker for Go32v2, so that may be faster (and we all, especially marcov, would be very curious to hear the timing results of that). Heck, even 16-bit Turbo Pascal 5.5 (freeware) would probably be less painful here.

[DamageX]

Replacing an old IDE harddisk with a Compact Flash card could speed things up.

[marcov]

Or you should try FreePascal 3.0.0 (which has good string support, something most BASIC fans need), which now has an internal linker for Go32v2, so that may be faster (and we all, especially marcov, would be very curious to hear the timing results of that).

The internal linker is definitely not for low memory conditions. The compiler, assembler/librarian and linker stages are in memory at the same time, and while that speeds up, it also might consume more memory for normal operation. Maybe it works if you only create small programs though.

[RockTheSchock]

Maybe you should develop on a modern pc and cross-compile for dos and transfer the exe files per floppy disk. You can buy an USB floppy disk drive for about 15 $. As alternative you could use dosbox with fbc dos version mounting a folder where the source files resides. So you can use an ide of your choice in windows / linux editing the files while in the dosbox window you compile / test them.

[marcov]

And if you use modern (read: 32-bit) tools, always disable the option to discard unused code (--gc-sections and friends on GCC, -XX "smartlinking" on FPC). Dead code optimization requires a disproportionate amount of memory.

Many paleo users instinctively enable it to get their binaries smaller, but if you develop on the limited system too, not doing that is the wiser option.