@bhabbott

Quote:

bhabbott wrote: Quote: Massi wrote: @bhabbott https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44581&forum=15&start=520&viewmode=flat&order=0 Finally we get to the heart of the matter... Quote: 68080 PROGRAMMING MODEL 16 64-Bit Address registers (A0-A15) 8 64-Bit General Purpose Data registers (D0-D7) 8 64-Bit FPU registers (Fp0-Fp7) 24 64-Bit General Purpose Data registers (E0-E23) which can be used by both ALU and FPU. 32 Data Registers (D0-D7, E0-E23) These registers are for bit and bit field (1 - 32 bits), byte (8 bits), word (16 bits), long-word (32 bits), and quad-word (64 bits) operations. D0-D7 can also be used as index registers in EA calculation. 32 FPU Registers (Fp0-Fp7,E0-E23) The FPU has access to 32 work registers. In addition to this FPU instructions can also use register also use the 8 Dn Register as source. Therefore the FPU has 32 registers it can update with calculation, and 40 registers it can use as source. 16 Address Registers (A0-A15) These registers can be used as software stack pointers, index registers, or base address registers. The base address registers can be used for [b]word and long-word operations. I presume nobody disputes this model, so it comes down to Karlos's 'naive' assumption that there would be "64-bit integer versions of the common arithmetic and logical operations". The fact that these imaginary instructions are not documented anywhere apparently wasn't a big enough clue, nor how this large number of extra instructions would be shoehorned into the opcode map. Karlos's excuse for his 'naivety' is that "It's generally the case when architectures expand register widths that they get new instruction variations to support the new width", which the 68080 did get with AMMX. But Karlos was expecting more than just some new 64 bit instructions - he thought the 'common' 32 bit ones would get a 64 bit variant too - even though this was not the case for CPUs with similar functionality in the past. From the Intel Pentium MMX to Pentium IV, AMD K6 to K6 III and Athon XP etc., the 'common' instructions remained 32 bit. Other processor lines that increased the register width of 'common' instructions typically switched to a whole new ISA (eg. 8085 -> 8086, Z80 -> Z8000, 6809 -> 68000). 68k remained 32 bit throughout its life, with only a few 64 bit instructions added in the 68020 (and then some taken away again in the 68060). Perhaps Karlos was thinking of x86 -> x64, but even that isn't quite true. In order to run 16 bit code the CPU has to be switched into 'real' mode, and then 64 bit instructions don't work, while some 'common' 32 bit instructions don't work in 64 bit mode. Clearly this method won't work for a drop-in CPU replacement used with an existing OS (i.e the Amiga). Anyway the 68080 is far different from x86, so assuming it will follow the same development path doesn't seem wise. You can't reasonably expect supposed 'undocumented' instructions to exist just because you think they should. Not mentioning imaginary instructions is not 'poor' documentation, it's correct documentation. The actual 68080 64 bit instructions are documented.

16-bit DOS apps can't run under 64-bit Windows, because the virtual-8086 mode isn't available in Long mode.

However, 16-bit protected mode is still available, so technically it's possible to run 16-bit Windows 3.x apps.

That's how WINE runs 16-bit Windows apps in X64 Linux.

Unfortunately, 64-bit Windows doesn't have the same capability, although the reason is not that 64-bit mode cannot run 16-bit instructions but because the significant part has been increased.


The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data.

https://learn.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications

Under the X64 Linux kernel, 16-bit protected-mode user space is available, but the virtual-8086 mode isn't.

Microsoft is just lazy when they dumped 16-bit Windows apps support.

Last edited by Hammer on 01-Dec-2022 at 01:12 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Karlos #94

I am pretty sure the user Gunnar has been also restricted for a month or so, that can be confirmed by the moderators.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Massi

Restricted why?

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@kolla

Well I guess "Gunnar" wound up a lot of his critics. As the opening of this thread alluded to.

_________________
Doing stupid things for fun...

@kolla #103

Well his presence was not welcomed by few users and then the discussions became soon turbolent (...), it is everything in the threads.

_________________
SAM440EP-FLEX @ 733 Mhz, AmigaOS 4.1 Update 1

@Karlos

Quote:

Karlos wrote: Shoehorned? Have a look at the existing opcode layout and acquaint yourself with the size field for common integer operations. It's a 2-bit field, 00: byte, 01: word, 10: long. Unless it's reserved for something else, 11 could be used to indicate a 64-bit integer size.

There's the problem - and it's a big one.

Take MOVE(A) for example, probably the most popular instruction and certainly one you would want to extend. It doesn't use the 2 bit field you mention. Instead bits 29 and 28 in the MOVE opcode are used, with 00 selecting all the other instructions before MOVEA. To do MOVE.Q you need to find space for another 4096 unique opcodes, which you can't get here.

But other opcodes do use bits 8 and 9 as you describe, so there must be some space there, right? Unfortunately not much. For example ADDQ and SUBQ don't use 'size' 11, but that combination is taken by Scc and DBcc. It is also used to distinguish SUBA from SUB and SUBX, CMPA from CMP and CMPM, and ADDA from ADD and ADDX. Shift and rotate instructions use it to specify operation on memory vs registers.

Most of the 'holes' related to existing instructions are already filled. However MOVEQ always has bit 8 set to 0. By setting it to 1 you have 11 bits to play with, giving 2048 unique instructions. AMMX uses it for register bank switching instructions. The Apollo team could have used this area to produce a limited set of 64 bit 'extended' instructions, but chose not to. I can understand why. We don't need 64 bit addressing, and 32 bits are enough for most integer code. SIMD is useful for the typical code that could do with being sped up on the Amiga, 64 bit 'normal' instructions less so.

Quote:

I said my assumption was naive, but it wasn't completely stupid. Moreover it is mentioned in a few of the common instructions documented for the 68080 that "quad" is a supported operand size, but it's rather hit and miss, which is why I asked in the first place.

Yes, quad is a supported operand size in AMMX. However it is only applicable to AMMX stuff, not normal 68k instructions.

Personally I'm fine with this. I would rather see Vampire specific stuff kept separate from normal code, like was done with MMX on x86. Otherwise we risk the same problem older PCs have now, with so much stuff requiring a 64 bit system for no good reason. Keeping the AMMX stuff separate helps to avoid polluting the scene with 'Amiga' code that actually requires a 68080 (a fear that many Vampire haters have).

Last edited by bhabbott on 30-Dec-2022 at 05:38 AM.

@bhabbott

Firstly I didn't say every instruction requiring a 64-bit form would be able to use the size field, but it is available for most common integer/logic operations. Other instructions would need a different encoding scheme that may require new or extended opcodes to support. Since code density is a factor, where you could use the size field, why wouldn't you?

Secondly, maybe you didn't follow the entire thread or where it came from but have a look here, and make sure you read the full description of the operation:

http://www.apollo-core.com/m68k/ADD.htm
http://www.apollo-core.com/m68k/SUB.htm

These happened to be the first pair I looked at and it clearly states "The size of the operation may be specified as byte, word, long, or Quad.". However the brief description states the more familiar 32-bit "byte, word, long".

If you work through the list of "vanilla" 68K instructions you'll find other references to quad. There is a completely separate documentation area for AMMX instructions.

I called out the original inconsistency in the documentation after being told to read it by someone claiming to be Gunnar, and asked what happens with 64 bit addresses, and other instructions where the size is either implied or can't trivially be encoded. It's what led to this thread in the first place.

Last edited by Karlos on 30-Dec-2022 at 09:40 AM.

_________________
Doing stupid things for fun...

Whether you like it or not, claiming to be a 64 bit architecture today comes with certain expectations. Specifically that you have 64-bit registers, address size (even if not all lines are attached to the outside world) and scalar instructions supporting 64-bit operands. Those in turn are typically then backed by 64 bit wide internal buses and 64-bit ALU. You don't claim your machine is 64-bit because you have a SIMD unit capable of performing some 64-bit wide operation. Otherwise intel would be the first to claim AVX2 was a 256-bit processor with 512 now the standard. x64, AArch64 and PPC64 stake their 64-bitness on the initial criteria above.

Apollo, on the face of it, does not appear to be a 64-bit processor. It may have 64-bit registers. It may use 64-bit internal data paths and it may have SIMD operations that use them, but that doesn't make it a 64-bit processor by any current definition of the term.

I can put a second 4 cylinder engine in the boot of my car that can only be used by some extremely niche private roads I never drive on and claim that it makes it a V8.

Last edited by Karlos on 30-Dec-2022 at 10:06 AM.
Last edited by Karlos on 30-Dec-2022 at 10:03 AM.

_________________
Doing stupid things for fun...

@Karlos

If Apollo identifies as 64bit processor then it is a 64bit processor you bigot!!!

@Bosanac

Nonbinary, eg? Maybe better suited to a transputer architecture.

_________________
Doing stupid things for fun...

@Thread

Are the new Icedrake boards worth it? I mean running Sonic and Diablo on an Amiga must be nice but beyond that the price and compatibility are issues. Still we are approaching a post-060 supply situation. The PiStorm will overrun the Vampires eventually IMHO.

P.S. I wasn't aware that the 64-bit CPU tag was a major selling point!?!

Last edited by BigD on 31-Dec-2022 at 12:18 AM.

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Bosanac

A modern 64-bit CPU should have a 64-bit pointer, 64-bit scalar registers, 64-bit scalar math, 64-bt logical memory address, physical memory address greater than 4 GB, and MMU that can pass the Linux test.

Last edited by Hammer on 31-Dec-2022 at 07:04 AM.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@Hammer

Agreed but if the board produces graphics artifacts from RTG or HDMI depending on the game, can't run the majority of Amiga demos without slowdown or glitches and needs the same degree of tweaking and setting up as a PiStorm which is order's of magnitude cheaper then it is all quite a mute point!

The Icedrake and the other V4s are good products but for the price they should stomp on decades old Blizzards/Cyberstorms and at least match the Warp1260s and TerribleFire cards for stability and compatibility!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios

@Hammer

In other shocking news, water is wet and the pope wears a frock.

@Bosanac

TIL bears defecate in the woods.

_________________
Doing stupid things for fun...

@BigD

yeh, but is that not demo coders expecting hardware to be x, not y or z, but want to behave like y, it no longer works as x or z, and so no longer works. Of course is lot flexibility as shown by Whdload can enable disable caches and set up hardware for range of different demos, as well patch broken demos and games so they work, on the wrong hardware.

Remember when old Pentium 90, came out people used to laugh at how insanity unplayable some of 386/486 games where.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@NutsAboutAmiga

People wrote games that demanded the entire processing power of older CPUs and had absolutely no wait states or other frame limiting mechanisms in them. They didn't need them because often when pushing old hardware you are struggling to reach a certain frame rate to begin with. DOOM was somewhat exceptional in that it had deliberate caps introduced since the get go. Lo and behold it didn't run too fast on newer CPUs.

A lot of classic Amiga games were limited to the hardware video refresh so these also scale to faster CPUs without being unplayable.

_________________
Doing stupid things for fun...

@bhabbott

Quote:

bhabbott wrote: Quote: Massi wrote: @bhabbott https://amigaworld.net/modules/newbb/viewtopic.php?topic_id=44581&forum=15&start=520&viewmode=flat&order=0 Finally we get to the heart of the matter... Quote: 68080 PROGRAMMING MODEL 16 64-Bit Address registers (A0-A15) 8 64-Bit General Purpose Data registers (D0-D7) 8 64-Bit FPU registers (Fp0-Fp7) 24 64-Bit General Purpose Data registers (E0-E23) which can be used by both ALU and FPU. 32 Data Registers (D0-D7, E0-E23) These registers are for bit and bit field (1 - 32 bits), byte (8 bits), word (16 bits), long-word (32 bits), and quad-word (64 bits) operations. D0-D7 can also be used as index registers in EA calculation. 32 FPU Registers (Fp0-Fp7,E0-E23) The FPU has access to 32 work registers. In addition to this FPU instructions can also use register also use the 8 Dn Register as source. Therefore the FPU has 32 registers it can update with calculation, and 40 registers it can use as source. 16 Address Registers (A0-A15) These registers can be used as software stack pointers, index registers, or base address registers. The base address registers can be used for [b]word and long-word operations. I presume nobody disputes this model, so it comes down to Karlos's 'naive' assumption that there would be "64-bit integer versions of the common arithmetic and logical operations". The fact that these imaginary instructions are not documented anywhere apparently wasn't a big enough clue, nor how this large number of extra instructions would be shoehorned into the opcode map.

It's not Karlos' naive assumption, rather what's coming out from reading this simple statement:

32 Data Registers (D0-D7, E0-E23)
These registers are for bit and bit field (1 - 32 bits), byte (8 bits), word (16 bits), long-word (32 bits), and quad-word (64 bits) operations.

64-bit operations aren't "second citizens" compared to 8/16/32-bit operations.

Something which is confirmed by Gunnar on the other thread, as well as other 68080 documentation available on its Discord channel.

If you don't know that, hey, it's YOUR problem.
Quote:

Karlos's excuse for his 'naivety' is that "It's generally the case when architectures expand register widths that they get new instruction variations to support the new width", which the 68080 did get with AMMX. But Karlos was expecting more than just some new 64 bit instructions - he thought the 'common' 32 bit ones would get a 64 bit variant too - even though this was not the case for CPUs with similar functionality in the past. From the Intel Pentium MMX to Pentium IV, AMD K6 to K6 III and Athon XP etc., the 'common' instructions remained 32 bit.

So?
Quote:

Other processor lines that increased the register width of 'common' instructions typically switched to a whole new ISA (eg. 8085 -> 8086, Z80 -> Z8000, 6809 -> 68000).

So?
Quote:

68k remained 32 bit throughout its life, with only a few 64 bit instructions added in the 68020 (and then some taken away again in the 68060).

So?
Quote:

Perhaps Karlos was thinking of x86 -> x64, but even that isn't quite true. In order to run 16 bit code the CPU has to be switched into 'real' mode, and then 64 bit instructions don't work, while some 'common' 32 bit instructions don't work in 64 bit mode.

Don't talk of things that you don't know.
Quote:

Clearly this method won't work for a drop-in CPU replacement used with an existing OS (i.e the Amiga).

Same as above. In fact, x86-64/x64 processors are drop-in replacements that can run existing o.ses for IA-32/x86 processors.

Whereas the same isn't the case for the Amiga and 68K processors, due to the fact that Motorola developed processors which were backward INcompatible.
Quote:

Anyway the 68080 is far different from x86, so assuming it will follow the same development path doesn't seem wise.

It's the exact contrary: it looks very very similar to x86/x64, since it expanded the ISA in a similar way (e.g. prefixes to extended data types to 64-bit and to select the additional registers which are now available)
Quote:

You can't reasonably expect supposed 'undocumented' instructions to exist just because you think they should. Not mentioning imaginary instructions is not 'poor' documentation, it's correct documentation. The actual 68080 64 bit instructions are documented.

Again, you don't know of what you talk about. Karlos was right and you clearly haven't most of 68080 documentation which is available.
Quote:

bhabbott wrote: @Karlos Quote: Karlos wrote: Shoehorned? Have a look at the existing opcode layout and acquaint yourself with the size field for common integer operations. It's a 2-bit field, 00: byte, 01: word, 10: long. Unless it's reserved for something else, 11 could be used to indicate a 64-bit integer size. There's the problem - and it's a big one. Take MOVE(A) for example, probably the most popular instruction and certainly one you would want to extend. It doesn't use the 2 bit field you mention. Instead bits 29 and 28 in the MOVE opcode are used, with 00 selecting all the other instructions before MOVEA. To do MOVE.Q you need to find space for another 4096 unique opcodes, which you can't get here. But other opcodes do use bits 8 and 9 as you describe, so there must be some space there, right? Unfortunately not much. For example ADDQ and SUBQ don't use 'size' 11, but that combination is taken by Scc and DBcc. It is also used to distinguish SUBA from SUB and SUBX, CMPA from CMP and CMPM, and ADDA from ADD and ADDX. Shift and rotate instructions use it to specify operation on memory vs registers. Most of the 'holes' related to existing instructions are already filled.

Thanks to the "wise" decision of Motorola...
Quote:

However MOVEQ always has bit 8 set to 0. By setting it to 1 you have 11 bits to play with, giving 2048 unique instructions. AMMX uses it for register bank switching instructions.

Wrong again: this isn't about AMMX, but about the 68080 core.
Quote:

The Apollo team could have used this area to produce a limited set of 64 bit 'extended' instructions, but chose not to. I can understand why.

No, you clearly do NOT understand: the "bank" prefix is precisely used to extend the existing instructions to 64-bit. Addresses included.
Quote:

We don't need 64 bit addressing,

"We" who? It's only Bruce "I'm the one which defines what's a real amiga and what everybody needs" Habott which don't needed it.

When do you start talking about yourself and NOT on behalf of ALL OTHER people?
Quote:

and 32 bits are enough for most integer code.

Pointless statement.
Quote:

SIMD is useful for the typical code that could do with being sped up on the Amiga,

Amiga never had a SIMD unit. And the one provided by the Apollo core is limited and not future-proof (since it's a very bad design).
Quote:

64 bit 'normal' instructions less so.

They are very useful. IF you have it AND you learn how to use them, of course.
Quote:

Quote: I said my assumption was naive, but it wasn't completely stupid. Moreover it is mentioned in a few of the common instructions documented for the 68080 that "quad" is a supported operand size, but it's rather hit and miss, which is why I asked in the first place. Yes, quad is a supported operand size in AMMX. However it is only applicable to AMMX stuff, not normal 68k instructions.

Wrong again: AMMX uses a DIFFERENT set of instruction which are located on... Line-F.

Whereas the BANK prefix is used for the existing 68K instructions.

When do you think to stop writing completely non-sense and study the Apollo core documentation?
Quote:

Personally I'm fine with this. I would rather see Vampire specific stuff kept separate from normal code, like was done with MMX on x86.

See above: it's already like that!
Quote:

Otherwise we risk the same problem older PCs have now, with so much stuff requiring a 64 bit system for no good reason.

Specify: no good reason FOR YOU!
Quote:

Keeping the AMMX stuff separate helps to avoid polluting the scene with 'Amiga' code that actually requires a 68080 (a fear that many Vampire haters have).

Again: it's ALREADY like that!

Go and study the documentation instead of ranting non-sense!

@Hammer

Quote:

Hammer wrote: 16-bit DOS apps can't run under 64-bit Windows, because the virtual-8086 mode isn't available in Long mode. However, 16-bit protected mode is still available, so technically it's possible to run 16-bit Windows 3.x apps. That's how WINE runs 16-bit Windows apps in X64 Linux. Unfortunately, 64-bit Windows doesn't have the same capability, although the reason is not that 64-bit mode cannot run 16-bit instructions but because the significant part has been increased. The primary reason is that handles have 32 significant bits on 64-bit Windows. Therefore, handles cannot be truncated and passed to 16-bit applications without loss of data. https://learn.microsoft.com/en-us/windows/win32/winprog64/running-32-bit-applications Under the X64 Linux kernel, 16-bit protected-mode user space is available, but the virtual-8086 mode isn't. Microsoft is just lazy when they dumped 16-bit Windows apps support.

I don't know how WINE and Linux work, but no 16-bit code at all can be executed in Long Mode (AKA x64's 64-bit mode).

16-bit protected code can only be run in Compatibility Mode (x64's 32-bit mode).

So, Microsoft hasn't issues like what you've reported.
Quote:

Hammer wrote: @Bosanac A modern 64-bit CPU should have a 64-bit pointer, 64-bit scalar registers, 64-bit scalar math, 64-bt logical memory address, physical memory address greater than 4 GB, and MMU that can pass the Linux test.

That's your own definition...

@Karlos

Quote:

Karlos wrote: So anyway, about those there 64 bit operations. What's the craic? Does anyone actually know?