Can I use Fasm to write a program that uses the 8087 c0-processor? If so how? Can you show me an example?

I don't know if it makes any difference whether its a co-CPU or integrated into it. The FPU instruction-set should be the same. Somebody correct me if I stand wrong here...
http://courses.ece.uiuc.edu/ece390/books/labmanual/inst-ref-general.html#INST-REF-F2XM1
...and look down from there

wow, there is something like 8087???

8087 was the first model of FPU for PC computers, in times when the FPU was in form of co-processor (additional processing unit you could plug into the motherboard). And yes, the instruction set is the same no matter whether FPU is a co-processor or is integrated into CPU.

In fact the encodings of FPU instructions are affected by the fact that they initially were instructions for the separate unit, as they are were in fact single ESC instruction of 8086, which escaped the command out to the co-processor, and the interpretation of escaped code was done by that separate unit - thus you possibly might have different co-processors with different instruction sets, but I have never heard of any instruction set for 8086 co-processors other that 8087 one.

hmmmm, isn't ESC opcode 0F, which was pop cs on 086?

No, 0F is just the part of two-byte encodings, it has no memonic itself.
The ESC instruction used opcodes D8-DF.
Quick description of ESC: http://library.n0i.net/hardware/i8086opcodes/#ESC

The link is broken, darn it. I've been searching for FPU ESC documentation for a while now.
http://library.n0i.net/hardware/i8086opcodes/#ESC
no longer exists. Is there another info source ?

and while I'm here, I noticed that FASM doesn't assemble
PUSH byte 20
or any value from 0-255
DB 106,#
assembles to 2 bytes, and that saves a byte for any 256 byte contests of mini code.
So it could be a useful thing.
The machine code runs on a 100% DOS compatible CPU
DB 0x6A = 106d = PUSH byte

Web Archive can help here, as it often does: https://web.archive.org/web/20060304153540/http://library.n0i.net/hardware/i8086opcodes/#ESC
The snapshot from 2006 should be the same thing that I originally intended to link to.

fasm optimizes such instructions automatically. When you assemble you get "6A 14" as output. And even when you assemble you get "6A 14", because fasm's syntax was designed with the assumption that assembly language is an abstraction layer where you specify what exact operation you need to perform and the assembler looks for the best (smallest) encoding that does it. There is no "push byte", as that would seem to imply decreasing SP only by 1, and there is no instruction that would perform such operation.

This semantic separation of the performed operation from the details of instruction encoding is what led me to design the extended syntax of fasm2, where you can alter the behavior of instruction encoder with additional hints next to (but separate from) the instruction: The default is still to have the assembler choose the shortest encoding it can.

The link worked but I have that info and it doesn't get me a working understanding.
Usage: ESC immed,src
what source, what immediate # where is it going, what is it doing, where is working example code that a person can learn from. I get 1000 words but I need the picture. Well that's where I'm stuck. But I don't need to get unstuck, I'm just working on a disassembler and have to learn a bit about, codes that I don't use. I can't get ESC to assemble anything. The latest lesson is that ESC is DB 15, + EXTension byte
Then I couldn't find any ESC in the intel info, and I have most all of it now.
My DOS SSTR.COM will find any text in any file in the directory, So it's not that I've overlooked the clues. it's just not there.
Info claimes that ESC is D8 to DF and i've already disassembled all that code and there is no ESC instruction. There is no value attached to ESC as is any other instruction. No one uses it in any code to learn from, so I was thinking it was dead code since FPU's were intagrated into the CPU chip.
PS I was doing PUSH BYTE 20 and failed. My other PUSH attempts turned out to be 3 byte code. Only the machine code DB 106,# worked, but in the morning when the FASM computer comes to life again, I'll beat it around for a while.
PS2, thanks for FASM, it really helps my creative desires get an outlet.

; Allow me to rephrase please. For 256 byte contests,
; FASM PUSHing values 128-255 could save a byte using machine code.
; DB 106,255 ;= PUSH byte 255


ALSO, ESC was a problem for me because Debuggers dump out code that doesn't exist or something, Microsoft DEBUG.exe couldn't do FPU code and a lot of things were wrong and TD.exe debugger was a mixed up mess also. and now it looks like NASM has the best syntax, for a lot of the machine code I'm trying to figure out. My DISn.com that alters the NASM nDISasm.exe output files gives me new info to work with also.
I made a program that dumps out an.asm file of machine code OP code number DB #, and an incremented #, followed by 5 NOPs = DB 144 and 256 lines of that assembled, then disassembled or run through a debugger showed me the mess I stepped into when I started my DIS assembler project. I have just about got it done though.

I was going through 256 byte contest code and found quite a few that would run in DOS but needed ESCape code. I want to share the ones that actually work without LOCKING UP THE CPU which most did. But it's not my code so I was hoping to get some info on that before I posted their work in working condition. Some are really good.

"105,255" is not "PUSH 255", it is "PUSH -1": "push 255" puts a zero-extended value on the stack, while "push -1" puts a sign-extended one. In 16-bit case you can therefore also rewrite this as: And in 64-bit case you'd need many more Fs there, but writing a negative number is universal.

Again, fasm's syntax focuses on what the instruction does, not how it is encoded. Once you correctly declare what operation you need, fasm is going to find the best encoding for you. This has always been my view of what an assembler is actually for, and fasm was from the beginning specialized in multi-pass assembly process to find shortest possible codes.

Thanks, I would have never guessed it to be a signed byte push or something.
Since I never use it, I never POPed it to check it's output. OOPs #735
& here is some more brain gas.

This is the kind of thing I needed to read somewhere, but it is nowhere.
So I wrote it, and I don't know if it is true or not.
So Please correct me where I am wrong. Anyone.

FPU-instructions DB 0xD8 - 0xDF were once CALLed ESCape codes
when FPU processors were seperate from CPU's,
because the instructions code needed to escape on the BUS to the FPU.
When FPU's were integrated into the CPU chip,
ESCape was no longer a TERM that was used to describe the process.
FPU ESC was never an instruction that had a value either.

Machine code DB 0x0F
was CALLed ESC as a term used to ESCape the single byte, 256 instruction limit of 8088 CPU's.
0-255 is all a byte can hold and that set the ONE BYTE instruction 8088 limit,
until, one of those bytes was used to ADD 256 more instructions,
and 0x0F was sacrificed for that, which became a COLLECT ALL for ODD & NEW instructions,
and the NEW 2 BYTE OPcode system was started using 0x0F.
A few 0x0F prefix codes were FPU OPcodes and that is where the confusion came from.
0x0F is not a FPU OPcode prefix, it is a prefix for some FPU code, and other instructions.
Much like DB 0x66 is a prefix for 32 bit 386+ code.

Some names were given to values in the INTEL alphabet 0-255 and 27 = 0x1B = ESC is one of them, which has nothing to do with FPU codeing.

So in conclusion, NOW, there is no ESC FPU code, instruction, term, prefix or anything ESC associated with the FPU.
"ESC" can not be used as an instruction or prefix in INTEL codeing.
There are no machine code values that disassemble to an instruction named, ESC.
People still use the term ESC & you have to evaluate what they are talking about by what else they say.