Click Here
home features news forums classifieds faqs links search
6068 members 
Amiga Q&A /  Free for All /  Emulation /  Gaming / (Latest Posts)
Login

Nickname

Password

Lost Password?

Don't have an account yet?
Register now!

Support Amigaworld.net
Your support is needed and is appreciated as Amigaworld.net is primarily dependent upon the support of its users.
Donate

Menu
Main sections
» Home
» Features
» News
» Forums
» Classifieds
» Links
» Downloads
Extras
» OS4 Zone
» IRC Network
» AmigaWorld Radio
» Newsfeed
» Top Members
» Amiga Dealers
Information
» About Us
» FAQs
» Advertise
» Polls
» Terms of Service
» Search

IRC Channel
Server: irc.amigaworld.net
Ports: 1024,5555, 6665-6669
SSL port: 6697
Channel: #Amigaworld
Channel Policy and Guidelines

Who's Online
52 crawler(s) on-line.
 15 guest(s) on-line.
 1 member(s) on-line.


 AMIGASYSTEM

You are an anonymous user.
Register Now!
 AMIGASYSTEM:  3 mins ago
 evilFrog:  10 mins ago
 emeck:  21 mins ago
 eliyahu:  31 mins ago
 amigakit:  35 mins ago
 AmigaPapst:  39 mins ago
 VooDoo:  1 hr 4 mins ago
 JACurley:  1 hr 5 mins ago
 thomas:  1 hr 6 mins ago
 Everblue:  1 hr 58 mins ago

/  Forum Index
   /  Amiga Development
      /  Apollo 68080 64-bit operations
Register To Post

Goto page ( 1 | 2 | 3 | 4 | 5 Next Page )
PosterThread
Karlos 
Apollo 68080 64-bit operations
Posted on 12-Oct-2022 11:18:47
#1 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 12-Oct-2022 17:25:22
#2 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

Are the docs just outdated/wrong?
Anyone here that has written code on one that can clarify?

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
cdimauro 
Re: Apollo 68080 64-bit operations
Posted on 12-Oct-2022 21:31:31
#3 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
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
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 12-Oct-2022 22:05:45
#4 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
kolla 
Re: Apollo 68080 64-bit operations
Posted on 12-Oct-2022 23:02:59
#5 ]
Elite Member
Joined: 20-Aug-2003
Posts: 2312
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
Profile     Report this post  
Hypex 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 2:22:13
#6 ]
Elite Member
Joined: 6-May-2007
Posts: 10826
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
Profile     Report this post  
Hypex 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 2:36:10
#7 ]
Elite Member
Joined: 6-May-2007
Posts: 10826
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
Profile     Report this post  
matthey 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 4:50:39
#8 ]
Super Member
Joined: 14-Mar-2007
Posts: 1684
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
Profile     Report this post  
cdimauro 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 5:14:09
#9 ]
Elite Member
Joined: 29-Oct-2012
Posts: 3084
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
Profile     Report this post  
OlafS25 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 6:32:54
#10 ]
Elite Member
Joined: 12-May-2010
Posts: 6171
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
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 13-Oct-2022 11:00:01
#11 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
matthey 
Re: Apollo 68080 64-bit operations
Posted on 14-Oct-2022 1:10:03
#12 ]
Super Member
Joined: 14-Mar-2007
Posts: 1684
From: Kansas

@Karlos
The Amiga world is a vampire.

https://www.youtube.com/watch?v=8-r-V0uK4u0

Last edited by matthey on 14-Oct-2022 at 01:13 AM.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 14-Oct-2022 10:18:26
#13 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 8:54:43
#14 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
From: As-sassin-aaate! As-sassin-aaate! Ooh! We forgot the ammunition!

Just a bump for the original question.

_________________
Doing stupid things for fun...

 Status: Offline
Profile     Report this post  
kamelito 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 19:29:20
#15 ]
Cult Member
Joined: 26-Jul-2004
Posts: 795
From: Unknown

@Karlos

I am pretty sure that this is not the right forum for such question.

 Status: Offline
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 19:57:02
#16 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
Bosanac 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 20:29:48
#17 ]
Regular Member
Joined: 10-May-2022
Posts: 203
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
Profile     Report this post  
Karlos 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 20:34:47
#18 ]
Elite Member
Joined: 24-Aug-2003
Posts: 3122
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
Profile     Report this post  
Bosanac 
Re: Apollo 68080 64-bit operations
Posted on 17-Oct-2022 20:37:00
#19 ]
Regular Member
Joined: 10-May-2022
Posts: 203
From: Unknown

@Karlos

Said the actress to the Bishop!

 Status: Offline
Profile     Report this post  
Bosanac 
Re: Apollo 68080 64-bit operations
Posted on 18-Oct-2022 16:16:22
#20 ]
Regular Member
Joined: 10-May-2022
Posts: 203
From: Unknown

@Karlos

Wo ist das ansässige Hardware-Genie Gunnar?

 Status: Offline
Profile     Report this post  
Goto page ( 1 | 2 | 3 | 4 | 5 Next Page )

[ home ][ about us ][ privacy ] [ forums ][ classifieds ] [ links ][ news archive ] [ link to us ][ user account ]
Copyright (C) 2000 - 2019 Amigaworld.net.
Amigaworld.net was originally founded by David Doyle