20 May 2024, 17:51 | #21 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
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.
|
20 May 2024, 17:57 | #22 |
Computer Nerd
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 48
Posts: 3,945
|
|
20 May 2024, 18:14 | #23 | |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
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' |
|
20 May 2024, 18:27 | #24 | |||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
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. Quote:
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. Quote:
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. |
|||
21 May 2024, 15:13 | #25 | ||
Registered User
Join Date: Jan 2019
Location: Germany
Posts: 3,457
|
Quote:
Quote:
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. |
||
21 May 2024, 16:46 | #26 | |
son of 68k
Join Date: Nov 2007
Location: Lyon / France
Age: 51
Posts: 5,379
|
Quote:
|
|
21 May 2024, 20:18 | #27 |
Moderator
Join Date: Nov 2004
Location: Eksjö / Sweden
Posts: 5,755
|
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. |
22 May 2024, 19:03 | #28 | |
Registered User
Join Date: Jun 2010
Location: PL?
Posts: 2,917
|
Quote:
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). |
|
28 May 2024, 08:53 | #29 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
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. |
|
28 May 2024, 09:16 | #30 | ||||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
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. Quote:
Quote:
Quote:
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. |
||||
28 May 2024, 09:36 | #31 |
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
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
|
28 May 2024, 11:13 | #32 | ||
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
Quote:
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. |
||
28 May 2024, 11:21 | #33 | |
Registered User
Join Date: Mar 2021
Location: Ligao, Free World North
Posts: 228
|
Quote:
|
|
28 May 2024, 11:42 | #34 | |||
Registered User
Join Date: Jul 2015
Location: The Netherlands
Posts: 3,464
|
Quote:
Quote:
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. Quote:
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 Last edited by roondar; 28 May 2024 at 16:53. Reason: Cleaned up the lay-out and rewrote some parts. |
|||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Pseudo Floating Point | Ernst Blofeld | Coders. General | 29 | 09 February 2021 20:03 |
StormC4 - floating-point number | emufan | Coders. C/C++ | 0 | 11 November 2017 21:32 |
Fast floating-point random numbers | Leffmann | Coders. Tutorials | 27 | 25 August 2016 01:59 |
Important Facts about Floating Point Numbers | Mrs Beanbag | Coders. General | 2 | 13 August 2016 21:14 |
Floating point without FPU | oRBIT | Coders. Asm / Hardware | 13 | 18 March 2015 23:11 |
|
|