Poster | Thread |
Karlos
|  |
Apollo 68080 64-bit operations Posted on 12-Oct-2022 11:18:47
| | [ #1 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| Maybe one for Gunnar before the angry mob get him banned...
I was curious about the 64-bit extensions in the 68080 and found the following developer documentation:
http://www.apollo-core.com/features.html#refins
It's a bit confusing. I naively assumed that there would be 64-bit integer versions of the common arithmetic and logical operations that would be indicated by specifying an appropriate type suffix (e.g. .q, for quad or simiar), even if the opcode encoding for these is very different than the existing 8/16/32-bit variants.
It doesn't seem to be the case though. For example, the documentation for ADD states: Quote:
ADD Dn, <ea>
ADD <ea> , Dn
ADD <ea> , Dn, Dm
Attributes: Size = (Byte, Word, Long)
Description: Adds the source operand to the destination operand using binary addition, and stores the result in the destination location. The size of the operation may be specified as byte, word, long, or Quad.
|
The description states the size can be quad, so maybe the attributes section is incorrect, but therea are no 64-bit examples given. The three operand version of the instruction doesn't include any documentation. What are Dm and Dn here? The ADDI immediate form of the instruction doesn't mention 64-bit support at all but does include another undocumented three-operand version.
Even simple unary operations like NEG seem to lack any 64-bit variant. In fact, the documentation for it states:
Quote:
If the number to change is longer than 32bit then use NEGX. |
The documentation for NEGX is again just the vanilla 680x0 variant that deals with 8/16/32 bit operands and the status flags for arbitrary length arithmetic.
Which integer operations support 64-bit operands?
Edit: thread title typo, obviously meant 68080
Last edited by Karlos on 12-Oct-2022 at 11:55 AM.
_________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 12-Oct-2022 17:25:22
| | [ #2 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| |
Status: Offline |
|
|
cdimauro
|  |
Re: Apollo 68080 64-bit operations Posted on 12-Oct-2022 21:31:31
| | [ #3 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Karlos: do you expect a reply from Gunnar?
As you can see, he prefer to spend a lot of time trying to defaming me and Matt, instead of giving answers to questions about what's supposed to be his Apollo 68080 core.
Which isn't a surprise, since I'm still waiting the encoding of the 64-bit MOVEA instruction.
The thing is that your questions raise similar problems to him, because it would become more evident the complete crap which he did designing his toy. |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 12-Oct-2022 22:05:45
| | [ #4 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @cdimauro
He suggested reading the manual. He's supposed to be getting ready for A37. I can wait.
In any case, I'm not certain it's Gunnar regardless. Last edited by Karlos on 12-Oct-2022 at 10:22 PM.
_________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
kolla
|  |
Re: Apollo 68080 64-bit operations Posted on 12-Oct-2022 23:02:59
| | [ #5 ] |
|
|
 |
Elite Member  |
Joined: 20-Aug-2003 Posts: 3352
From: Trondheim, Norway | | |
|
| @Karlos
Maybe you should demand him to send you a copy of his ID, like he does with everyone on his forum who he “bans”. _________________ B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC |
|
Status: Offline |
|
|
Hypex
 |  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 2:22:13
| | [ #6 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @Karlos
It could be a case of incomplete documentation. Or simply a copypasta job. After all the 68080 project as to copy the 68K before it adds the modifications. So the public docs may lack behind. But, given they need a solid specification before modifying the core, they should really have a solid explanation of what each instruction is doing. Otherwise how do they know what they are doing and what it does?
In the case of ADD they missed quad in attributes. But mention it in description.
I've seen examples where an API was vague and needed work but a CPU ISA somewhat major. |
|
Status: Offline |
|
|
Hypex
 |  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 2:36:10
| | [ #7 ] |
|
|
 |
Elite Member  |
Joined: 6-May-2007 Posts: 11351
From: Greensborough, Australia | | |
|
| @cdimauro
MOVEA is a good point. Since all A-type instructions operate in 32 bit size in the address register, regardless of operand size. Are the 68080 address registers 64 bit or just the data registers?
If only data then MOVEA can be disregarded as it would left as standard. However, if address registers are also 64 bit this presents a problem. A-type is implicit 32 bit. Just like MOVEQ is implicit 32 bit. It needs a 64 bit version with extra size. As would LEA.
Next is for what purpose. 64 bit data is useful for optimisation. The 68K ISA could do 64 bit operations in later variants but split into dual registers. But for 64 bit pointers you need a 64 bit OS. They don't have one. Except for AROS maybe. But AROS is an AmigaOS copy. It can be compiled as 64 bit so maybe that is a plan. But a real 64 bit AROS won't be compatible with 32 bit Amiga apps. |
|
Status: Offline |
|
|
matthey
|  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 4:50:39
| | [ #8 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2451
From: Kansas | | |
|
| Hypex Quote:
MOVEA is a good point. Since all A-type instructions operate in 32 bit size in the address register, regardless of operand size. Are the 68080 address registers 64 bit or just the data registers?
If only data then MOVEA can be disregarded as it would left as standard. However, if address registers are also 64 bit this presents a problem. A-type is implicit 32 bit. Just like MOVEQ is implicit 32 bit. It needs a 64 bit version with extra size. As would LEA.
|
OPA instructions sign extend to the address register size before performing the operation.
movea.w d0,a0 ; sign extend d0.w to a0 size and move to a0 adda.w d0,a0 ; sign extend d0.w to a0 size and add to a0
A 64 bit 68k CPU should have 64 bit address registers. The current 32 bit OPA instructions should behave similarly.
movea.l d0,a0 ; sign extend d0.l to a0 size and move to a0 adda.l d0,a0 ; sign extend d0.l to a0 size and add to a0
There would also be new OPA instructions.
movea.q d0,a0 ; 64 bit register move adda.q d0,a0 ; 64 bit register add
Easy enough for most address instruction handling. LEA isn't a problem as either previous OPA instructions have sign extended to the register size or the index register size can be specified which is sign extended to the register size. As Karlos pointed out, PEA requires a new 64 bit size (PEA.Q) while the old 32 bit size (PEA.L) is kept for compatibility and systems that want to avoid the performance reduction of 64 bit pointers. The 68k address registers behave more like RISC GPU integer registers.
MOVEQ is implicitly longword sized on the 68k which it could remain on a 64 bit 68k but there are other choices.
1) MOVEQ remains implicitly 32 bit 2) MOVEQ sign extends to 64 bit 3) MOVEQ zero extends from 33 bit to 64 bit (upper longword is zeroed)
Option #1 is the worst choice due to partial register stalls. Option #2 is the most useful as negative immediates remain useful for 64 bit. Option #3 is what x86-64 does for all 32 bit operations in registers which not only avoids partial register stalls but avoids REX prefixed in some cases to convert to 64 bit (example: XOR.D r0,r0 is shorter than XOR.Q r0,r0 to clear a register). A 64 bit 68k ISA could do the same for all OP.L instructions which always avoids partial register stalls. There are some cases where it doesn't work as well like MOVEQ and it is inconsistent with the way data registers work on the 68k for smaller size integer datatypes. Address registers would still be sign extended to the register size which is optimal and perfectly consistent with the 68k while there is a choice to be made for data registers.
Hypex Quote:
Next is for what purpose. 64 bit data is useful for optimisation. The 68K ISA could do 64 bit operations in later variants but split into dual registers. But for 64 bit pointers you need a 64 bit OS. They don't have one. Except for AROS maybe. But AROS is an AmigaOS copy. It can be compiled as 64 bit so maybe that is a plan. But a real 64 bit AROS won't be compatible with 32 bit Amiga apps. |
Without a real MMU, there are a limited number of 64 bit OSs available for testing. Lack of addresses above 32 bit (~4GiB) makes it difficult to test 64 bit addressing although memory could likely be mapped to higher addresses for testing if 64 bit addressing is working in registers and memory (needs PEA.Q and maybe more). Legacy 68k code would not work either. The best solution for AmigaOS is likely to leave most of the AmigaOS in 32 bit address space using 32 bit pointers for compatibility in structures which has the advantage of using less memory and being higher performance. Newer 64 bit aware programs could allocate memory with a MEMF_64bit flag which could return memory outside the 32 bit address range. A bit could be set in Amiga executables indicating they could be loaded into 64 bit address space as well. Some AmigaOS functions would need to become 64 bit aware and some care would need to be taken not to pass 64 bit pointers to non-aware AmigaOS functions which don't support them.
Most 64 bit OSs have process isolation and each process/task/thread is mapped starting at the bottom of the 32 bit address space. AmigaOS programs would more often be mapped wherever there memory is available so improved PC relative addressing would be a major asset (including writes but not compatible or consistent without a separate 64 bit mode) as 64 bit absolute addressing is very inefficient. Even the real Gunnar doesn't seem to care about 64 bit addressing or a real MMU (could protect new code at least) though. There isn't much motivation from AmigaOS developers either I guess because the 68k Amiga has such a small footprint that 64 bit addressing isn't necessary yet. We don't even have a 68k Amiga with 1GiB of memory yet. As long as the 68k is only in FPGA, there isn't much need and that is what the real Gunnar is planning for. A semi-modern GPU may require 64 bit addressing and that isn't happening in a FPGA 68k SoC.
Last edited by matthey on 13-Oct-2022 at 04:56 AM. Last edited by matthey on 13-Oct-2022 at 04:55 AM.
|
|
Status: Offline |
|
|
cdimauro
|  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 5:14:09
| | [ #9 ] |
|
|
 |
Elite Member  |
Joined: 29-Oct-2012 Posts: 4127
From: Germany | | |
|
| @Karlos
Quote:
Karlos wrote: @cdimauro
He suggested reading the manual. |
The manual doesn't report it, as you have already seen.
So, your question is right and deserve an answer. However, and as I've already said, I doubt the it'll come. Quote:
He's supposed to be getting ready for A37. I can wait. |
You opened the thread much before his message that he's busy with the A37. In the meanwhile he had a lot of time digging on web archive desperately seeking for something about TiNA, and of course writing several posts for defaming me.
Instead of providing some answer on HIS project. Quote:
In any case, I'm not certain it's Gunnar regardless. |
I'm pretty confident that, unfortunately he's the original one.
@Hypex
Quote:
Hypex wrote: @cdimauro
MOVEA is a good point. Since all A-type instructions operate in 32 bit size in the address register, regardless of operand size. |
Indeed. It was a quick and easy way to verify if he was telling bullsh*t or not about this specific point. But, of course, he NEVER replied my after several weeks: guess why... Quote:
Are the 68080 address registers 64 bit or just the data registers? |
Yes. Quote:
If only data then MOVEA can be disregarded as it would left as standard. However, if address registers are also 64 bit this presents a problem. A-type is implicit 32 bit. Just like MOVEQ is implicit 32 bit. It needs a 64 bit version with extra size. As would LEA. |
And not only that: addresses need to be push as 64-bit on the stack, for obvious reasons. As well return addresses of JSR and BSR instructions.
Guess what: they are NOT doing it... Quote:
Next is for what purpose. 64 bit data is useful for optimisation. The 68K ISA could do 64 bit operations in later variants but split into dual registers. But for 64 bit pointers you need a 64 bit OS. They don't have one. Except for AROS maybe. But AROS is an AmigaOS copy. It can be compiled as 64 bit so maybe that is a plan. But a real 64 bit AROS won't be compatible with 32 bit Amiga apps. |
Correct.
@ferrels
Quote:
ferrels wrote: @Karlos
Quote:
Maybe one for Gunnar before the angry mob get him banned... |
Gets banned from the Apollo forums for poor behavior and then expects an answer to his question from others who have been banned from same forum.....priceless! LOL!
AmigaWorld never fails to entertain! |
Had a bad night, Steve? You seems to be so much confused.
Maybe you were thinking of (completely) different people. Care to clarify who?
@matthey
Quote:
matthey wrote: Hypex Quote:
MOVEA is a good point. Since all A-type instructions operate in 32 bit size in the address register, regardless of operand size. Are the 68080 address registers 64 bit or just the data registers?
If only data then MOVEA can be disregarded as it would left as standard. However, if address registers are also 64 bit this presents a problem. A-type is implicit 32 bit. Just like MOVEQ is implicit 32 bit. It needs a 64 bit version with extra size. As would LEA.
|
OPA instructions sign extend to the address register size before performing the operation.
movea.w d0,a0 ; sign extend d0.w to a0 size and move to a0 adda.w d0,a0 ; sign extend d0.w to a0 size and add to a0
A 64 bit 68k CPU should have 64 bit address registers. The current 32 bit OPA instructions should behave similarly.
movea.l d0,a0 ; sign extend d0.l to a0 size and move to a0 adda.l d0,a0 ; sign extend d0.l to a0 size and add to a0
There would also be new OPA instructions.
movea.q d0,a0 ; 64 bit register move adda.q d0,a0 ; 64 bit register add
Easy enough for most address instruction handling. LEA isn't a problem as either previous OPA instructions have sign extended to the register size or the index register size can be specified which is sign extended to the register size. As Karlos pointed out, PEA requires a new 64 bit size (PEA.Q) while the old 32 bit size (PEA.L) is kept for compatibility and systems that want to avoid the performance reduction of 64 bit pointers. The 68k address registers behave more like RISC GPU integer registers.
MOVEQ is implicitly longword sized on the 68k which it could remain on a 64 bit 68k but there are other choices.
1) MOVEQ remains implicitly 32 bit 2) MOVEQ sign extends to 64 bit 3) MOVEQ zero extends from 33 bit to 64 bit (upper longword is zeroed)
Option #1 is the worst choice due to partial register stalls. Option #2 is the most useful as negative immediates remain useful for 64 bit. Option #3 is what x86-64 does for all 32 bit operations in registers which not only avoids partial register stalls but avoids REX prefixed in some cases to convert to 64 bit (example: XOR.D r0,r0 is shorter than XOR.Q r0,r0 to clear a register). A 64 bit 68k ISA could do the same for all OP.L instructions which always avoids partial register stalls. There are some cases where it doesn't work as well like MOVEQ and it is inconsistent with the way data registers work on the 68k for smaller size integer datatypes. Address registers would still be sign extended to the register size which is optimal and perfectly consistent with the 68k while there is a choice to be made for data registers.
Hypex Quote:
Next is for what purpose. 64 bit data is useful for optimisation. The 68K ISA could do 64 bit operations in later variants but split into dual registers. But for 64 bit pointers you need a 64 bit OS. They don't have one. Except for AROS maybe. But AROS is an AmigaOS copy. It can be compiled as 64 bit so maybe that is a plan. But a real 64 bit AROS won't be compatible with 32 bit Amiga apps. |
Without a real MMU, there are a limited number of 64 bit OSs available for testing. Lack of addresses above 32 bit (~4GiB) makes it difficult to test 64 bit addressing although memory could likely be mapped to higher addresses for testing if 64 bit addressing is working in registers and memory (needs PEA.Q and maybe more). Legacy 68k code would not work either. The best solution for AmigaOS is likely to leave most of the AmigaOS in 32 bit address space using 32 bit pointers for compatibility in structures which has the advantage of using less memory and being higher performance. Newer 64 bit aware programs could allocate memory with a MEMF_64bit flag which could return memory outside the 32 bit address range. A bit could be set in Amiga executables indicating they could be loaded into 64 bit address space as well. Some AmigaOS functions would need to become 64 bit aware and some care would need to be taken not to pass 64 bit pointers to non-aware AmigaOS functions which don't support them.
Most 64 bit OSs have process isolation and each process/task/thread is mapped starting at the bottom of the 32 bit address space. AmigaOS programs would more often be mapped wherever there memory is available so improved PC relative addressing would be a major asset (including writes but not compatible or consistent without a separate 64 bit mode) as 64 bit absolute addressing is very inefficient. Even the real Gunnar doesn't seem to care about 64 bit addressing or a real MMU (could protect new code at least) though. There isn't much motivation from AmigaOS developers either I guess because the 68k Amiga has such a small footprint that 64 bit addressing isn't necessary yet. We don't even have a 68k Amiga with 1GiB of memory yet. As long as the 68k is only in FPGA, there isn't much need and that is what the real Gunnar is planning for. A semi-modern GPU may require 64 bit addressing and that isn't happening in a FPGA 68k SoC.
|
All correct. And Gunnar clearly stated that his interested only on 32-bit for addresses.
However address registers are 64-bit. But the documentation says nothing about how the processor works. |
|
Status: Offline |
|
|
OlafS25
|  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 6:32:54
| | [ #10 ] |
|
|
 |
Elite Member  |
Joined: 12-May-2010 Posts: 6472
From: Unknown | | |
|
| @Karlos
the apollo team is preparing the important A37 event where they join with lots of people, make presentations and sell hardware. I already wondered that Gunnar has all the time left for discussions on forums. He will certainly take part again next week. |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 13-Oct-2022 11:00:01
| | [ #11 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @matthey
Quote:
A 64 bit 68k CPU should have 64 bit address registers. |
Mind. Blown. I need to let that sink in a while.
Quote:
The current 32 bit OPA instructions should behave similarly.
movea.l d0,a0 ; sign extend d0.l to a0 size and move to a0 adda.l d0,a0 ; sign extend d0.l to a0 size and add to a0
There would also be new OPA instructions.
movea.q d0,a0 ; 64 bit register move adda.q d0,a0 ; 64 bit register add
Easy enough for most address instruction handling |

Sorry, I couldn't resist! Last edited by Karlos on 13-Oct-2022 at 11:05 AM. Last edited by Karlos on 13-Oct-2022 at 11:05 AM.
_________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
matthey
|  |
Re: Apollo 68080 64-bit operations Posted on 14-Oct-2022 1:10:03
| | [ #12 ] |
|
|
 |
Elite Member  |
Joined: 14-Mar-2007 Posts: 2451
From: Kansas | | |
|
| |
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 14-Oct-2022 10:18:26
| | [ #13 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @matthey
I'm not sure I understood the reference, but I certainly haven't listened to smashing pumpkins in a long time. _________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 8:54:43
| | [ #14 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| |
Status: Offline |
|
|
kamelito
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 19:29:20
| | [ #15 ] |
|
|
 |
Cult Member  |
Joined: 26-Jul-2004 Posts: 836
From: Unknown | | |
|
| @Karlos
I am pretty sure that this is not the right forum for such question. |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 19:57:02
| | [ #16 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @kamelito Quote:
kamelito wrote: @Karlos
I am pretty sure that this is not the right forum for such question. |
Amiga / Development
Seems perfectly cromulent to me._________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
Bosanac
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 20:29:48
| | [ #17 ] |
|
|
 |
Regular Member  |
Joined: 10-May-2022 Posts: 257
From: Unknown | | |
|
| @Karlos
Quote:
Amiga / Development Seems perfectly cromulent to me. |
Can you not see where you went wrong?
Admittedly you are sane and have emotionally matured past toddlerhood, so it’s understandable why not.
It is not t3h reel Amiga!!!!1111Eleventyone! |
|
Status: Offline |
|
|
Karlos
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 20:34:47
| | [ #18 ] |
|
|
 |
Elite Member  |
Joined: 24-Aug-2003 Posts: 4843
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition! | | |
|
| @Bosanac
Quote:
Admittedly you are sane and have emotionally matured past toddlerhood |
I've been accused of a few things, but that could be a first._________________ Doing stupid things for fun... |
|
Status: Offline |
|
|
Bosanac
|  |
Re: Apollo 68080 64-bit operations Posted on 17-Oct-2022 20:37:00
| | [ #19 ] |
|
|
 |
Regular Member  |
Joined: 10-May-2022 Posts: 257
From: Unknown | | |
|
| @Karlos
Said the actress to the Bishop! |
|
Status: Offline |
|
|
Bosanac
|  |
Re: Apollo 68080 64-bit operations Posted on 18-Oct-2022 16:16:22
| | [ #20 ] |
|
|
 |
Regular Member  |
Joined: 10-May-2022 Posts: 257
From: Unknown | | |
|
| @Karlos
Wo ist das ansässige Hardware-Genie Gunnar? |
|
Status: Offline |
|
|