Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Any other library is welcome as well!

Thank you in advance!

Kind regards, Ruud Baltissen

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with 64-bit IEEE, sounds like it's going be rather slow.

Hallo Bart,

Do these machines also have an 8087? That would help!

Some do. But that means some don't and thus we either need to emulate 8087 instructions or need to replace them with 8088 ones.
 

Otherwise, a software library operating to modern standards, and working
with 64-bit IEEE, sounds like it's going be rather slow.

For the moment I would be happy with a 16-bits library.

Kind regards, Ruud Baltissen

On 2019-09-18 17:19, Ruud Baltissen wrote:> Hallo Bart,
 >
 >> Do these machines also have an 8087? That would help!
 >
 > Some do. But that means some don't and thus we either need to emulate 8087
 > instructions or need to replace them with 8088 ones.
 >
 >> Otherwise, a software library operating to modern standards, and working
 >> with 64-bit IEEE, sounds like it's going be rather slow.
 >
 > For the moment I would be happy with a 16-bits library.

Borland/Turbo Pascal came with an x87 emulator in the RTL. A long time ago I
disassembled it, and included it in the archive. Look for, long wrapping URL:

https://archive.org/download/2012.11.24.ftp-garbo-mirror/2012.11.24.garbo.uwasa.fi.zip/garbo.uwasa.fi%2Fpub%2Fpc%2Fgarbo%2Fpc%2Fturbopa7%2Fbpl70v20.zip
Virtually uncommented raw disassembly in EM86.ASM. I also think that the
emulation wasn't complete.

Robert
--
Robert AH Prins
robert(a)prino(d)org

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with 64-bit IEEE, sounds like it's going be rather slow.

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

--
Rick C. Hodgin

On 18-Sep-19 23:47, Robert Prins wrote:

On 2019-09-18 17:19, Ruud Baltissen wrote:> Hallo Bart,
 >
 >> Do these machines also have an 8087? That would help!
 >
 > Some do. But that means some don't and thus we either need to emulate 8087
 > instructions or need to replace them with 8088 ones.
 >
 >> Otherwise, a software library operating to modern standards, and working
 >> with 64-bit IEEE, sounds like it's going be rather slow.
 >
 > For the moment I would be happy with a 16-bits library.

Borland/Turbo Pascal came with an x87 emulator in the RTL. A long time ago I
disassembled it, and included it in the archive. Look for, long wrapping URL:

https://archive.org/download/2012.11.24.ftp-garbo-mirror/2012.11.24.garbo.uwasa.fi.zip/garbo.uwasa.fi%2Fpub%2Fpc%2Fgarbo%2Fpc%2Fturbopa7%2Fbpl70v20.zip Virtually uncommented raw disassembly in EM86.ASM. I also think that the
emulation wasn't complete.

Robert

Try 8087.asm or m8087.asm http://annex.retroarchive.org/cdrom/psl-v2n6//PRGMMING/DOS/ASM/index.html

--
Alex

On 18.09.19 14:05, Rick C. Hodgin wrote:

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not
just the PC. I'm also programming my own Pascal compiler that should run
under that OS. It is able to compile itself, it only outputs macros and it
is up to the assembler plus an INC file to turn it in a running program. So
far I was able to create programs that run on a Commodore 64. I'm now busy
now to create an INC file for the 8088. Outputting a string under my OS or
MS-DOS goes fine. But I also need to fill the macros needed for the
mathematical functions. I could invent the wheel twice but handling REALs
is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can
anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with
64-bit IEEE, sounds like it's going be rather slow.

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

On my dosmachines fortran(MS 5.1) and C(MS 6.00a) support
linking with FPU and without.

On 18/09/2019 13:05, Rick C. Hodgin wrote:

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with 64-bit IEEE, sounds like it's going be rather slow.

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

If emulating 8087 then that puts extra demands on the emulation library, especially if emulating its internal 64-bit calculations.

When I was coding this stuff (sorry source code long since lost), I coded to my own specifications, and did little checking other than for divide-by-zero. To make it easier, and a bit faster, I think I arranged for the exponent+sign to fit exactly into the top byte of 32 bits.

(While an older version for the 8-bit Z80, which had very limited 16-bit capability, used a 24-bit format: 8-bit exponent/sign, and 16-bit mantissa.)

On 19.09.19 0:58, Sjouke Burry wrote:

On 18.09.19 14:05, Rick C. Hodgin wrote:

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not
just the PC. I'm also programming my own Pascal compiler that should run
under that OS. It is able to compile itself, it only outputs macros and it
is up to the assembler plus an INC file to turn it in a running program. So
far I was able to create programs that run on a Commodore 64. I'm now busy
now to create an INC file for the 8088. Outputting a string under my OS or
MS-DOS goes fine. But I also need to fill the macros needed for the
mathematical functions. I could invent the wheel twice but handling REALs
is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can
anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with
64-bit IEEE, sounds like it's going be rather slow.

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

On my dosmachines fortran(MS 5.1) and C(MS 6.00a) support
linking with FPU and without.

Oh, and with and without emulator.

The DJGPP project includes an 80387 emulator if that helps, look for
v2misc/wmemu*.zip

On 9/18/2019 7:50 PM, Bart wrote:

On 18/09/2019 13:05, Rick C. Hodgin wrote:

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

If emulating 8087 then that puts extra demands on the emulation library, especially if emulating its internal 64-bit calculations.

Yes.  The x86 CPU has a feature to allow software emulation of the
full x87 instruction set.  Whenever an x87 instruction is encountered
in x87 emulation mode, it signals an interrupt which dispatches to a
handler.  There the software simulates the operation, and then iret
back and it keeps going.  Slow, but it provides an easy x87 operation
when all you have is an 8086 or 8088.

The 80286, 80386, and 80486SX allowed those abilities as well.  All
CPUs 80486DX and later have built-in FPUs.

When I was coding this stuff (sorry source code long since lost), I coded to my own specifications, and did little checking other than for divide-by-zero. To make it easier, and a bit faster, I think I arranged for the exponent+sign to fit exactly into the top byte of 32 bits.

(While an older version for the 8-bit Z80, which had very limited 16-bit capability, used a 24-bit format: 8-bit exponent/sign, and 16-bit mantissa.)

IEEE-754 compliance is difficult.  If you don't go for 100% compliance
it's not so hard, but then it's really only good for what you want to
use it for.

Some people have used the emulation ability to install ISA support for
alternate hardware.  They re-purpose the x87 FPU opcodes to be their
own operations, which can access a card, send data to it, allow a co-
processor to handle some computation, read back the result, and then
maintain the alternate environment state.

Very flexible design if you don't need the FPU.

--
Rick C. Hodgin

On 9/18/2019 6:26 PM, Alex McDonald wrote:

Try 8087.asm or m8087.asm http://annex.retroarchive.org/cdrom/psl-v2n6//PRGMMING/DOS/ASM/index.html

Nice opcode macros, but it's not the actual emulation library source
code.

--
Rick C. Hodgin

On 9/18/2019 6:58 PM, Sjouke Burry wrote:

On 18.09.19 14:05, Rick C. Hodgin wrote:

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not
just the PC. I'm also programming my own Pascal compiler that should run
under that OS. It is able to compile itself, it only outputs macros and it
is up to the assembler plus an INC file to turn it in a running program. So
far I was able to create programs that run on a Commodore 64. I'm now busy
now to create an INC file for the 8088. Outputting a string under my OS or
MS-DOS goes fine. But I also need to fill the macros needed for the
mathematical functions. I could invent the wheel twice but handling REALs
is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can
anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with
64-bit IEEE, sounds like it's going be rather slow.

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

On my dosmachines fortran(MS 5.1) and C(MS 6.00a) support
linking with FPU and without.

Yes.  It allowed function calls to be generated instead of x87/x387
opcodes.  IIRC, the emulated functionality wasn't fully IEEE-754
compliant.  Also, 80-bit support was later phased out, leaving only
32-bit and 64-bit support in the language, and (IIRC) the emulation
library, so code you have in MS 6.0 would no longer compile.

--
Rick C. Hodgin

On 9/17/2019 3:54 AM, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Any other library is welcome as well!

Thank you in advance!

Kind regards, Ruud Baltissen

Soft CPU apps like Bochs are open source.  They include full x87
support, though to be honest it may be implemented via pass-thru
computation on the host CPU.

If you really want to tackle this project, read up on how the FPU
operates, how the CPU monitors the FPU instruction steam and sits
idly by while the FPU processes those opcodes.  When the FPU is
not present, how it signals an emulation interrupt.

In either case, creating your own library for each opcode would
be a decent task, but it is doable.  If you aren't looking to be
fully IEEE-754 compliant, it would be notably easier.  And if you
wanted to do something like what Bart did, and re-define the FPU
features on your soft-8088/8087 combo, then you have a lot of leg
room for feature sets.

--
Rick C. Hodgin

Rick C. Hodgin wrote:

On 9/18/2019 7:50 PM, Bart wrote:

On 18/09/2019 13:05, Rick C. Hodgin wrote:

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

If emulating 8087 then that puts extra demands on the emulation library, especially if emulating its internal 64-bit calculations.

Yes.  The x86 CPU has a feature to allow software emulation of the
full x87 instruction set.  Whenever an x87 instruction is encountered
in x87 emulation mode, it signals an interrupt which dispatches to a
handler.  There the software simulates the operation, and then iret
back and it keeps going.  Slow, but it provides an easy x87 operation
when all you have is an 8086 or 8088.

The faster option was to compile the program so that each 8087 instruction was compiled into a CALL to the emulator routine:

If the 8087 hw was available, the emulator would patch the call site into the actual 8087 opcodes plus any NOPs needed to fill up the typically 3-byte call. If the opcode was in fact longer than the call, then the call would in fact be padded so that it could be replaced.

Since all this code was always single-threading there was no issue with patching running code, no risk of overwriting stuff that was currently running somewhere.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 19/09/2019 07:21, Terje Mathisen wrote:

Rick C. Hodgin wrote:

Yes.  The x86 CPU has a feature to allow software emulation of the
full x87 instruction set.  Whenever an x87 instruction is encountered
in x87 emulation mode, it signals an interrupt which dispatches to a
handler.  There the software simulates the operation, and then iret
back and it keeps going.  Slow, but it provides an easy x87 operation
when all you have is an 8086 or 8088.

The faster option was to compile the program so that each 8087 instruction was compiled into a CALL to the emulator routine:

If the 8087 hw was available, the emulator would patch the call site into the actual 8087 opcodes plus any NOPs needed to fill up the typically 3-byte call. If the opcode was in fact longer than the call, then the call would in fact be padded so that it could be replaced.

The OP mentioned a Pascal compiler. If so, then it might be easier to let that generate different output depending on whether an 8087 was available or not.

Alternatively, all code could use function calls for each FP op. Then one of two libraries for those calls could be included: either one that just uses the 8087, or one that does the software emulation.

If the software is expected to work well enough with emulation, then those call overheads will not be significant.

On 9/19/2019 2:21 AM, Terje Mathisen wrote:

Rick C. Hodgin wrote:

On 9/18/2019 7:50 PM, Bart wrote:

On 18/09/2019 13:05, Rick C. Hodgin wrote:

I searched for it but couldn't find it.  There used to be an 8087.asm
app that worked with DOS.  It would install a software emulator for
the 8086/8088 CPUs so it would work with native x87 FPU instructions.
I may still have it on one of my Programmer's Heaven CDs from back in
the BBS days.

It was fully IEEE-754 compliant and could be adapted.  In fact, IIRC,
a version of that program was used to find the famous Pentium FDIV
bug, as the software version was reporting correctly, and the Pentium
was reporting incorrectly, over a particular range of inputs.

If emulating 8087 then that puts extra demands on the emulation library, especially if emulating its internal 64-bit calculations.

Yes.  The x86 CPU has a feature to allow software emulation of the
full x87 instruction set.  Whenever an x87 instruction is encountered
in x87 emulation mode, it signals an interrupt which dispatches to a
handler.  There the software simulates the operation, and then iret
back and it keeps going.  Slow, but it provides an easy x87 operation
when all you have is an 8086 or 8088.

The faster option was to compile the program so that each 8087 instruction was compiled into a CALL to the emulator routine:

If the 8087 hw was available, the emulator would patch the call site into the actual 8087 opcodes plus any NOPs needed to fill up the typically 3-byte call. If the opcode was in fact longer than the call, then the call would in fact be padded so that it could be replaced.

Since all this code was always single-threading there was no issue with patching running code, no risk of overwriting stuff that was currently running somewhere.

In re-reading the OP, I think he's not looking to create an emulator,
but rather to write his OS + toolset and run it on real 8086/8 hardware.

If I were going to approach the OP's task, I would provide both the
hardware emulator, and the link-in support libraries to my compiler,
that way apps can run natively on the CPU if they don't have support
from a link-in support library (though it's arguable if it's his OS,
and the Pascal compiler is the only one available, what else would
there be?), but for those that do they can take advantage both ways.

I'm a "let's go all in" kind of guy (to use a phrase).

--
Rick C. Hodgin

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with 64-bit IEEE, sounds like it's going be rather slow.

Slow is a relative term.  The original 8086/8088 ran at 4.77 MHz.
Modern CPUs could run full emulation solely in software at probably
300 MHz if not faster.  BGB has a simulation using his verilog-
based logic that runs at 50 MHz, and that's simulating circuits.

For a long time I've wanted to re-purpose the x87 opcodes to have
a different kind of math library.  I've wanted to add arbitrary-
precision support in lieu of 80-bit reals.  Use real hardware for
32-bit and 64-bit, but when using 80-bit loads and operations on
80-bit loaded values, use GMP and MPFR.  Haven't gotten around to
it yet.  Too many other things to do first.

--
Rick C. Hodgin

Hallo Robert,

Borland/Turbo Pascal came with an x87 emulator in the RTL. A long time ago I
disassembled it, and included it in the archive. Look for, long wrapping URL:

That looks very good and very well documented. My first impression was that I was looking at the disassembly of mathematical part of the BASIC of my Commodores. One idea is/was to convert the 6502 code into 8088 code and to start with that. As said, my Pascal compiler is able to generate programs for the C64 and that includes quite some mathematical functions. I most case I lean on subroutines of the Kernal and BASIC ROM of the C64. Translating these routines could be an option. But why inventing the wheel twice if there is a change I can find it around here some where?

Thank you very much!

Kind regards, Ruud Baltissen

Hallo Rick,

In re-reading the OP, I think he's not looking to create an emulator,
but rather to write his OS + toolset and run it on real 8086/8 hardware.

Correct.

(though it's arguable if it's his OS, and the Pascal compiler is the
only one available, what else would there be?)

At this moment my OS can boot, can start files and I'm busy implementing handling directories. First of all: it is slow but steady fun project.

This Pascal compiler should be one of it first tools. At this moment it runs under DOS and is only to produce programs containing "write" and "writeln" because so far only the macros for these statements have been filled with ML instructions. It can compile itself and only of all macros have been filled it should run under my own OS.

Kind regards, Ruud Baltissen

On 9/20/2019 10:52 AM, Ruud Baltissen wrote:

Hallo Rick,

In re-reading the OP, I think he's not looking to create an emulator,
but rather to write his OS + toolset and run it on real 8086/8 hardware.

Correct.

(though it's arguable if it's his OS, and the Pascal compiler is the
only one available, what else would there be?)

At this moment my OS can boot, can start files and I'm busy implementing handling directories. First of all: it is slow but steady fun project.

This Pascal compiler should be one of it first tools. At this moment it runs under DOS and is only to produce programs containing "write" and "writeln" because so far only the macros for these statements have been filled with ML instructions. It can compile itself and only of all macros have been filled it should run under my own OS.

Kind regards, Ruud Baltissen

If you're interested in a fast and easy solution, the best thing
would be to create a reader for the existing Microsoft, Borland,
or someone else's 16-bit DOS soft-FPU libraries.  They should be
available almost everywhere.

Write a parser for accessing content in those .LIB files, and
then write a translator to translate from your Pascal calling
convention to the stdcall convention they likely use (or figure
out what they use by default), and you should be able to use
that existing asset.

Another option would be to create your own .COM file (flat, 64 KB
max size with those libraries), and add entry points into it, and
let the DOS compiler + linker do the work.  The .COM file is a
straight-forward format that might even be easier to use.  You
can place pseudo-opcode "markers" in your file so you can find
the entry points.  You can define them at the head of the .COM file,
etc.  Many possible solutions.

Existing assets like those old DOS libraries may be your best way
to go.  Just make sure you have a valid license to use them, or
that the software is defunct.  Digital Mars may be a way to go as
well, as they have old compilers that support DOS and pre-Win95
Windows.

--
Rick C. Hodgin

On 19/09/2019 13:41, Rick C. Hodgin wrote:

On 9/18/2019 6:51 AM, Bart wrote:

On 17/09/2019 08:54, Ruud Baltissen wrote:

Hello,

I'm working on my own OS, meant to run on various 8088 based machines, not just the PC. I'm also programming my own Pascal compiler that should run under that OS. It is able to compile itself, it only outputs macros and it is up to the assembler plus an INC file to turn it in a running program. So far I was able to create programs that run on a Commodore 64. I'm now busy now to create an INC file for the 8088. Outputting a string under my OS or MS-DOS goes fine. But I also need to fill the macros needed for the mathematical functions. I could invent the wheel twice but handling REALs is not easy. But Google wasn't my friend this time.

So I'm looking for a mathematical library in assembler for the 8088. Can anybody help, please?

Do these machines also have an 8087? That would help!

Otherwise, a software library operating to modern standards, and working with 64-bit IEEE, sounds like it's going be rather slow.

Slow is a relative term.  The original 8086/8088 ran at 4.77 MHz.
Modern CPUs could run full emulation solely in software at probably
300 MHz if not faster.  BGB has a simulation using his verilog-
based logic that runs at 50 MHz, and that's simulating circuits.

For a long time I've wanted to re-purpose the x87 opcodes to have
a different kind of math library.  I've wanted to add arbitrary-
precision support in lieu of 80-bit reals.  Use real hardware for
32-bit and 64-bit, but when using 80-bit loads and operations on
80-bit loaded values, use GMP and MPFR.  Haven't gotten around to
it yet.  Too many other things to do first.

Arbitrary-precision floating point is going to be much slower than even emulation of 8087. But in either case, overheads of using a function call are going to be insignificant.

So I can't see the need to re-use 8087 opcodes. In any case, those are designed to work with a small stack of 80-bit floating point values (in that the operands will often be implicit). Arbitrary precision numbers would have a different representation, and need to be put elsewhere, and the results also need to be placed elsewhere

On 9/20/2019 3:48 PM, Bart wrote:

On 19/09/2019 13:41, Rick C. Hodgin wrote:

For a long time I've wanted to re-purpose the x87 opcodes to have
a different kind of math library.  I've wanted to add arbitrary-
precision support in lieu of 80-bit reals.  Use real hardware for
32-bit and 64-bit, but when using 80-bit loads and operations on
80-bit loaded values, use GMP and MPFR.  Haven't gotten around to
it yet.  Too many other things to do first.

Arbitrary-precision floating point is going to be much slower than even emulation of 8087.

I often tell the people I work with when it comes to the algorithms
we're writing and why we're writing them that way, "We don't build
bridges for sunny days.  We build bridges for hurricanes and 200 mph
winds and houses and trees slamming into them in the flood waters."
The same goes for our software algorithms.

Arbitrary precision emulation via hardware mechanisms would be a
nice feature in some cases.  GMP and MPFR are pretty fast, even
for arbitrary precision.  They're just many orders of magnitude
slower than hardware FPU ops, but they also have the benefit of
carrying their work out to far more significant digits.

It all depends on what you need.

But in either case, overheads of using a function call are going to be insignificant.

Agreed.

So I can't see the need to re-use 8087 opcodes. In any case, those are designed to work with a small stack of 80-bit floating point values (in that the operands will often be implicit). Arbitrary precision numbers would have a different representation, and need to be put elsewhere, and the results also need to be placed elsewhere

Absolutely.

--
Rick C. Hodgin