68000 and floating point

[roondar]

I tend to agree with those who suggest using the built-in libraries. While it is true you might have a small amount of extra overhead vs direct FPU code, it does fix all compatibility issues in one go and if better libraries are made available (which has happened a few times in the past), your code can benefit from the better performance and/or fixes.

[Thorham]

Originally Posted by roondar

While it is true you might have a small amount of extra overhead vs direct FPU code

What about 68060 FPU code where a 68040 or 68060 without FPU isn't fast enough?

[roondar]

Originally Posted by Thorham

What about 68060 FPU code where a 68040 or 68060 without FPU isn't fast enough?

When talking about software for 'higher end' Amiga's, I tend to be of the opinion that it's better to offer the software such that it'll run too slow on systems that don't meet minimum specs rather than having it not run at all.

That said, this is all just my opinion. Doing things differently is certainly possible. After all, I mostly don't use the OS in any code I write (albeit that code is squarely aimed at low-end Amiga configurations like the A500 with 1MB), so I can't really say different approaches from using the OS are 'wrong'

[kerravon]

Originally Posted by Photon

C was hacky in the 80s and 90s. I'm not familiar with C90, but C also rolled its own string and memory handling, dispensed with strict typing, atom definition, etc.

I'm not a language expert. I picked C on the advice from someone at work around 1987. And I've used it ever since and I don't have the skills to find fault with it.


After I have implemented my entire toolchain and OSes and emulators on all platforms I care about, to my satisfaction - I would (at least nominally) be happy to repeat the whole process in Pascal or Java or Rust or whatever.


But I'm nearly 57 so I'm expecting to die before completion of just the C90 implementation.

Amiga libraries are standalone and distributed with the OS. As such, together they function as something like a public, documented API. Devs are not expected to compile or link them, or redistribute them.

I'm not disputing anything you are saying - but bear in mind I don't have AmigaDOS (quibbling aside), I only have my own mini-clone.


So what's traditionally best practice may not be applicable.


And I'm running my mini-clone on an ARM machine running qemu-m68k.


And I consider having the actual 68881 instructions inline to be "neat" and "normal" (outside of the Amiga at least) - that's what the instructions are for.


I am looking for neatness (and remember that beauty is in the eye of the beholder) of my own executables. You can buy a real 68881 or you can use SoftIEEE or equivalent, or you can not run any of my applications that use floating point - I don't mind - I'm not selling anything or working for someone.

This means that they don't have to be part of your distributed executable, but also that the burden is on you to either specify an OS version and stick to that, or check the version of AmigaOS (technically, the lib version) for those lib functions that have been changed or added over time, to support older versions "and up".

And also this solution won't work when I wish to build and run PDOS-generic executables (no Amiga support), nor when I build and run Atari executables, nor when I wish to build and run Linux executables. The onus is on the end user to provide the required hardware rather than me fudge my executable (or not have my Atari etc executable work at all).


I'm not saying my opinion is the only correct one. And my opinion is only tentative anyway. I saw someone describe someone else as "strong opinions, lightly-held". Which likely applies to me too except my opinions aren't even strong and I'm not claiming to have any particular knowledge or expertise.

[Thomas Richter]

Originally Posted by kerravon

I'm not a language expert. I picked C on the advice from someone at work around 1987. And I've used it ever since and I don't have the skills to find fault with it.

C as a language does not define a specific floating point format. It only provides some fairly general rules. IEEE is one particular implementation that is sufficient to satisfy the requirements of C, but those are not very demanding either.

Originally Posted by kerravon

And I consider having the actual 68881 instructions inline to be "neat" and "normal" (outside of the Amiga at least) - that's what the instructions are for.

Except that they are not generally available on the Amiga. You can make them available in a sense. SoftIEEE exists, and it actually even runs on a 68000, but then quite slowly as it emulates the entire FPU. Faster (a lot faster) but less precise floating point you find in the math.library of the Os, which is actually based on a Motorola "fast floating point" library.



Concerning 68020 vs. 68000: There is a lot more than just long division and multiplication, and emulating missing 68020 instructions on the 68000 may not be feasible. I'm not even sure whether the 68000 traps all of them - for example, the addressing modes with index register multiplications may possibly go unnoticed by the 68000, but I am not sure.



For the 68040 and 68060, also note that you need some support library as they do ot implement all floating point instructions either. The 68060 is even missing some integer instructions.

[meynaf]

Originally Posted by Thomas Richter

Concerning 68020 vs. 68000: There is a lot more than just long division and multiplication, and emulating missing 68020 instructions on the 68000 may not be feasible. I'm not even sure whether the 68000 traps all of them - for example, the addressing modes with index register multiplications may possibly go unnoticed by the 68000, but I am not sure.

68000 traps anything that is detectable at first code word. So new 68020+ addressing modes will not trap - both new modes and scale factor are simply ignored.

[Photon]

Kerravon: I give an eagle-eye view of floating-point as it pertains to writing software and languages, and some things to consider. This is solely because your dialect is old, from when CSci was gaining traction, only for C to ruin everything. Every crash every user has ever had, and the poor reputation of software, was and is the fallout of using the wrong tool for the job: a low-level language for high-level software.

This is why I don't recommend trapping. It's an established trend to wrap everything in exceptions and handle them, but like all carte blanche habits it will cause poor readability. Why consistently crash your code (with manually written or inserted templates) when a check suffices? It will reduce performance greatly, while offering no advantages whatever. Exception checks belong on the module or application level.

I tend to argue with arguments that have a strong foundation, and this can sometimes be misinterpreted as personal opinion. Please interpret it as a desire to bring CSci advantages such as using public, documented APIs, and making beautiful, high-level languages. If it's an opinion, it's a platform-agnostic one.

As applied to Amiga, this would make me a rebel: anti-Unix/Linux-beard. So Amiga arrives and builds this support, and someone says, "No FPU or wrong FPU, please recompile"? No. That's just a step back to the dawn of time; the stone age. A recompile has always been available, and it's absolute horror for releasing software and a cause of all the versionitis seen on all platforms.

[pandy71]

Originally Posted by kerravon

Sorry - could you clarify that? For the Amiga 500 specifically, did someone sell a "peripheral" that had a 68881? It wasn't mentioned on Wikipedia.


And what is it that was supported "from 68020" if the 68000 already supported it? ie what changed with the 68020 that made you mention it?

Well... Wikipedia can be incorrect especially on Amiga related topics but not only.
Technically it possible to use 68881 with pre-68020 CPU's.
68020 introduced HW interface to use 68881 as coprocessor (so if there is 68881 instruction it is automatically handled by 68881) - 68000 and other pre-68020 CPU's have no HW coprocessor interface and as such 68881 instruction must be processed by 68000 as special instruction and 68881 can be used as I/O device.
I will upload "AN947_MC68881_Floating-Point_Coprocessor_as_a_Peripheral_in_a_M68000_System_[Motorola_1987_37p].pdf" to The Zone.

https://eab.abime.net/zone/AN947_MC6...987_37p%5D.pdf

Instead 68881 you can use way more numeric processors with 68k family in such fashion (i.e. I/O peripheral) - for example it should be possible to hook Intel 80287, Weitek 3167 and other numeric processors.

Of course emulating coprocessors as illegal instruction or line F or Line A or TRAP is not efficient as HW interface but if you design your code well then you can use 68881 directly (for example you can use float library that explicitly use 68881 in I/O mode without time costly special exceptions).

[kerravon]

Originally Posted by meynaf

Atari ST apps certainly do TRAPs. And quite a lot of them, actually (trap #1, trap #2, trap #13, trap #14, even line-A).

Turns out that I was asking the wrong question, plus not being able to see the forest for the trees.

Since I have control over the C library, all I need to do is channel my code into a trap68000() similar to a int86x() and then have a global variable that says whether to really do the trap, or to execute a callback that will do the equivalent of that trap.

In order to set that global variable, in the Atari case I can use a reserved location in the basepage.

Note that in the Amiga I created a mechanism to use D7 as an override for sysbase.

But in both cases - with support from a linker - which we now have control of - I could in fact arrange for a variable to appear at the first 4 bytes of BSS. If run under real Atari/Amiga then it will be 0. If run under my emulator, then it will set that 4 bytes to a pointer with callback functions.

I'm only attempting to run my own executables, so nothing more needs to even be done.

More importantly, the failed-then-not-failed attempt to create a mini Atari clone has made me realize the above, and I can apply that technique to MSDOS and the mainframe (MVS). So that has triggered a new branch of development.

[kerravon]

Originally Posted by Photon

Kerravon: I give an eagle-eye view of floating-point as it pertains to writing software and languages, and some things to consider. This is solely because your dialect is old, from when CSci was gaining traction, only for C to ruin everything. Every crash every user has ever had, and the poor reputation of software, was and is the fallout of using the wrong tool for the job: a low-level language for high-level software.

Note that I am not recommending C for general application writing. I am not offering an opinion at all.

My interest is challenging assembler programmers who insist everything should be done in assembler and everything else is a joke.

Ok, so I'm probably 50 times more productive in C than assembler. But I still expect to maintain touch with assembler. And I expect to debug at the assembler level. And know what the C compiler is generating as I write the C code.

I just don't want to WRITE in assembler. Reading is OK.

And I have never found anything wrong with any C compiler I have used. They all generate assembler code that I am happy with. And the C compiler is a godsend.

The applications I am writing - an operating system, a C library etc, are meant to be in direct competition with the assembler equivalent.

Noting that I concede defeat when going up against MSDOS. Such tight memory constraints are not an area I can compete in. I more-or-less need 2 MiB of memory to be able to do what I want to do (have a simple OS in C, and run the C compiler under that). And even that assumes a cut down C compiler. The version (3.2.3) of GCC I am using - just the executable itself - is about 3 MB in size. Nevermind when you are trying to compile a large program with full optimization.

As such, I'm really only trying to compete with assembler starting with the 80286.

This is why I don't recommend trapping. It's an established trend to wrap everything in exceptions and handle them, but like all carte blanche habits it will cause poor readability. Why consistently crash your code (with manually written or inserted templates) when a check suffices? It will reduce performance greatly, while offering no advantages whatever. Exception checks belong on the module or application level.

I don't use exceptions at all. C90 doesn't have such a thing unless you're talking about signals. I never use those.

I tend to argue with arguments that have a strong foundation, and this can sometimes be misinterpreted as personal opinion. Please interpret it as a desire to bring CSci advantages such as using public, documented APIs, and making beautiful, high-level languages. If it's an opinion, it's a platform-agnostic one.

I use documented APIs too. All my code is pure C90. micro-emacs and everything has been written in just C90. Well - the Amiga mini-clone has a bit of necessary assembler in it to create the jump table.

As applied to Amiga, this would make me a rebel: anti-Unix/Linux-beard. So Amiga arrives and builds this support, and someone says, "No FPU or wrong FPU, please recompile"? No. That's just a step back to the dawn of time; the stone age. A recompile has always been available, and it's absolute horror for releasing software and a cause of all the versionitis seen on all platforms.

This *is* a platform that I am creating. An entire infrastructure in fact.

And I have no real opinion on what applications running under it should do. Although I do note that there is no maths library available if you were hoping that one would be there. And nor will there be one unless someone writes a public domain maths library. My OSes are pure public domain. So are any executables that I produce using my C library. Only the toolchains have copyrighted freeware in them.

That's just the limit of what has been contributed to the public domain.

It's not everything you may want.

It's not nothing either.

[roondar]

Originally Posted by kerravon

My interest is challenging assembler programmers who insist everything should be done in assembler and everything else is a joke.

An interesting starting point for sure. There can't be that many of those. I mean, I'm sure they exist, but looking at my personal experience: I pretty much exclusively program assembly for the Amiga and certainly don't think other languages are a joke. And I'm pretty sure that goes for most of us 'assemblers' on here

[kerravon]

Originally Posted by Thomas Richter

Concerning 68020 vs. 68000: There is a lot more than just long division and multiplication, and emulating missing 68020 instructions on the 68000 may not be feasible.

I am only concerned about instructions that are generated by gcc 3.2.3 or vbcc.

I'm not even sure whether the 68000 traps all of them - for example, the addressing modes with index register multiplications may possibly go unnoticed by the 68000, but I am not sure.

Ok, so they apparently do go unnoticed. And I don't know if gcc 3..2.3 generates such things.

I'm in a much stronger position now. I have some experience in 68000 assembly doing the setjmp/longjmp.

And I have the ability to test 68000 executables.

And I just found that I have the ability to restrict the CPU to 68000:

[kerravon@paul-pinebook xxx]$ qemu-m68k -cpu m68020 ./bios.exe pdptest.exebios startingabout to execute program with entry point C080202Creturn from called program is hex center command, exit to exitbios exiting[kerravon@paul-pinebook xxx]$ qemu-m68k -cpu m68000 ./bios.exe pdptest.exeIllegal instruction (core dumped)[kerravon@paul-pinebook xxx]$


Also I note that gcc 3.2.3 has the ability to generate 68000 instructions while still allowing 68881 instructions, which is what I need.

modsi3, mulsi3, udivsi3, umodsi3, divsi3 are the unresolved externals when I switch to -m68000 -m68881 on gccami.

Another thing is that I now have routines like this for ARM32, but I suspect that is for a different reason. I'll see if I can get it to work so that I can switch to 68000, not have code generation issues, and SoftIEEE can take care of the odd occasions where I use floating point.

Also I looked at that document on 68881 as a peripheral, and it can also operate the same way - ie the floating point can be trapped. I assume SoftIEEE doesn't have the ability to drive the 68881 as a peripheral though - but a software implementation is fine by me anyway.

[kerravon]

Originally Posted by roondar

An interesting starting point for sure. There can't be that many of those. I mean, I'm sure they exist, but looking at my personal experience: I pretty much exclusively program assembly for the Amiga and certainly don't think other languages are a joke. And I'm pretty sure that goes for most of us 'assemblers' on here

Well, this is close enough to the level I like to compete. Is there a reason you don't use C on the Amiga? Is the quality of the code generated insufficient? Not willing to profile your code and only use assembler if there is some time-critical section? You don't care about the ability to port all your hard work to some other platform effortlessly?

[roondar]

Originally Posted by kerravon

Well, this is close enough to the level I like to compete. Is there a reason you don't use C on the Amiga? Is the quality of the code generated insufficient?

Until quite recently, this was certainly part of the reason. This part of it has mostly gone away with recent, far better, C compilers becoming available for the Amiga.

Not willing to profile your code and only use assembler if there is some time-critical section?

I never liked switching between C and assembler. IMHO it's best to either code using higher level languages and accept whatever benefits and drawbacks that brings, or code in assembly and accept it's benefits and drawbacks.That's not to say I think it's 'wrong' to code in C with some assembly (or even in assembly with some C), it's just not what I like to do.

If I do mix languages, it's almost always in separate programs - such as having a lookup table generator in Python and the code that uses said LUT in assembly, or similar constructs like that.

You don't care about the ability to port all your hard work to some other platform effortlessly?

My Amiga code is written for the Amiga and it's unique chipset. In many ways it's explicitly designed to be 'unportable' as portability was never the goal

The reason for me to use assembly? Well, there's several: I like the challenge, I like the direct HW access without needing to jump through syntax hoops to do so in C, I like how I can get all 'close and personal' to the CPU and learn/see exactly what it is doing, I like how some concepts are immediately clear simply by looking at the addressing mode being used and I like to figure things out using only those base building blocks the CPU and surrounding hardware offer, rather than using abstractions. I also find 68000 assembly just to be a nice environment to work in, whereas I've always found C to be 'meh' at best in terms of syntax and environment. This was true even when I still coded C professionally. I guess I'm one of the few that just doesn't like C syntax much.

Note that this is all of course only relevant for my Amiga hobby coding. When it comes to code (both old and current) written for my work, I do things rather differently and would not make the same choices