Amiga.org

Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: Atheist on March 18, 2003, 09:37:02 AM

Title: CPU Instructions Q.
Post by: Atheist on March 18, 2003, 09:37:02 AM
1. How many different assembler instructions are available on a G4 CPU?

2. An instruction that goes into the CPU is upto 32 bits wide, but, because there's less than (I'm gonna guess) 256 instructions, does that mean that, in a file, it's 1 byte per instruction, storage wise?

3. When an instruction is pulled into ram, does it use up 4 bytes of ram? i.e. it gets converted to a 4 byte (long word), providing it was 1 byte on disk?

4. If 3 is true, when xp goes to 64 bits (and/or RISC), it will be all over for their (not)os? Considering xp uses 1.3+ Gigs of HD space already.

AmigaOne! Programming is work AND entertainment.
Title: Re: CPU Instructions Q.
Post by: jaokim on March 18, 2003, 12:45:08 PM
These might interest you:http://cad.iaingibson.co.uk/g4_instruction.htm (http://cad.iaingibson.co.uk/g4_instruction.htm)

heres some altivec instructions (http://developer.apple.com/hardware/ve/instruction_crossref.html).
It seems to be more thean 256, and that is just the altivec-instructions.
Dont know if the pages might answer your questions.
Title: Re: CPU Instructions Q.
Post by: Atheist on March 18, 2003, 01:28:07 PM
At altivec instructions (http://developer.apple.com/hardware/ve/instruction_crossref.html), I counted 113

while http://cad.iaingibson.co.uk/g4_instruction.htm (http://cad.iaingibson.co.uk/g4_instruction.htm)
 says Altivec, alone, has 162 instructions.

So 162 + x = y instructions.

At http://cad.iaingibson.co.uk/g4_features.htm (http://cad.iaingibson.co.uk/g4_features.htm)
/*
The G4s Velocity Engine
The secret behind the G4’s revolutionary performance is its aptly named Velocity Engine (or it’s AltiVec Technology). This technology is the heart of a supercomputer, but has now been miniaturized onto a sliver of silicon and added to a personal computer processor. The Velocity Engine can process data in 128-bit chunks, instead of the smaller 32-bit or 64-bit chunks used in traditional processors (it’s the 128-bit vector processing technology used in scientific supercomputers — except that Apple, Motorola and IBM have added 162 new instructions to speed up computations). In addition, it can perform four (and in some cases eight) 32-bit floating-point calculations in a single clock cycle — this is two to four times faster than traditional processors take to do the same operations.

Velocity Engine (AltiVec) technology operations are performed on multiple data elements by a single instruction. This is often referred to as SIMD (single instructions, multiple data) parallel processing.
*/

AmigaOne! So strong that it's scary?
Title: Re: CPU Instructions Q.
Post by: itix on March 18, 2003, 01:47:56 PM
Every instruction in the PPC processor is four bytes long. No less, no more.

Download some PDFs from mot and learn :-)
Title: Re: CPU Instructions Q.
Post by: MiniBobF on March 18, 2003, 01:50:41 PM
Quote
1. How many different assembler instructions are available on a G4 CPU?

2. An instruction that goes into the CPU is upto 32 bits wide, but, because there's less than (I'm gonna guess) 256 instructions, does that mean that, in a file, it's 1 byte per instruction, storage wise?

3. When an instruction is pulled into ram, does it use up 4 bytes of ram? i.e. it gets converted to a 4 byte (long word), providing it was 1 byte on disk?

4. If 3 is true, when xp goes to 64 bits (and/or RISC), it will be all over for their (not)os? Considering xp uses 1.3+ Gigs of HD space already.

AmigaOne! Programming is work AND entertainment.


Well from a hardware point of view (Op codes, not assembler mnemonics) then the data and instructions are 32bits long in total (In a 32-bit core). Possibly a 16bit instruction with 16bits of data. The current range of PPC's are still 32 bit (although the data bus is 64bits wide) the instruction itself is MAX of 32-bits... that's not to say the data relating to that instruction must fit into the remaining 32-bits, it could be in the next word etc.

I got shot down in flames a month or two ago for saying that the current range of PPC (not PPC970 etc) are 32 bit... I say again - 32bit cores with addtional capacity for data. (Hence why the data bus is 64-bits wide)

Neil Thomas, AKA MiniBobf
Title: Re: CPU Instructions Q.
Post by: filson on March 18, 2003, 02:03:14 PM
@MiniBobF In regards to the 16bit instruction + 16bit data.
The G4/G3 processors aligns all instructions on 32bit boundries so even if an instruction takes 8 bit, it will still be padded with 0's till it's 32bit long. Thats part of the MSB/LSB thing. PPC has MSB where bit 31 is 1 bit in instruction, optionaly padding till bit 0.
Title: Re: CPU Instructions Q.
Post by: Atheist on March 18, 2003, 02:11:24 PM
Hello itix, and MiniBobF,

Would that mean that when we go to 64 bit CPU's, every instruction stored in an executable command takes up 8 bytes of ram and 8 bytes of disk space?

As I said in my first post, msxp, is gonna go down IN FLAMES!!! They're at 1 -1.5 gigs of HD space now, then combine that with RISC, where you need more commands!!

AmigaOne! "You have no chance to survive make your time!!  HA HA HA HA!!!!!"
Title: Re: CPU Instructions Q.
Post by: filson on March 18, 2003, 02:23:10 PM
Thats not realy going to be a problem as 120G harddisk is dirt cheap. Windows can become as bloated as it ever want.  :-D

What's more interesting is how many patches they have to release because they don't know how to program efficiently. RISC isn't realy that lenient on bloat ware.
Title: Re: CPU Instructions Q.
Post by: Hardboy on March 18, 2003, 02:39:31 PM
All instructions is 32bit, both in ram and on disk. Normally 5-14 bits goes to upcode which identifies the instruction, and the rest of the bits defines which resgisters to use or what immediate data to use.
Title: Re: CPU Instructions Q.
Post by: N7VQM on March 18, 2003, 03:31:18 PM
Quote

Atheist wrote:
As I said in my first post, msxp, is gonna go down IN FLAMES!!! They're at 1 -1.5 gigs of HD space now, then combine that with RISC, where you need more commands!!


I must have missed something.  Where did Microsoft say they were planning support for any so-called RISC chips?  AFAIK, MS isn't going to support 64-bit anything besides IA64 or x86-64.
Title: Re: CPU Instructions Q.
Post by: Atheist on March 18, 2003, 06:29:30 PM
Hello N7VQM,

Well, it appears to be a grey area, accordinng to here (http://www.arstechnica.com/cpu/1q99/ia-64-preview-1.html) and here (http://www.arstechnica.com/cpu/1q99/ia-64-preview-2.html). The author doesn't call it RISC or CISC, because there's a new boy in town, by the name of E.P.I.C.

So billy will have to make a choice, throw the baby out with the bath water, or program for backwards compatability, either way, it will be a HUGE set back. Code BLOAT or almost total incompability with old apps.

I think we are at a nexus of computing, where Amiga Inc.'s fortunes could literally change overnight.

Imagine if they could pull off another Commodore 64, except this time, the 64 stands for 64 BIT!!!! :-D

That's why my signature at OS.Amiga.com/Forums is "AOS 4.0 will create a new type of computing!"

AmigaOne! Less is more!
Title: Re: CPU Instructions Q.
Post by: N7VQM on March 18, 2003, 08:24:36 PM
Quote

Atheist wrote:
Hello N7VQM,

The author doesn't call it RISC or CISC, because there's a new boy in town, by the name of E.P.I.C.


There's not many consumer processors that are truely RISC or CISC. There may not be any.  Read another of Hannibal's articles. (http://www.arstechnica.com/cpu/4q99/risc-cisc/rvc-1.html)

Quote

So billy will have to make a choice, throw the baby out with the bath water, or program for backwards compatability, either way, it will be a HUGE set back. Code BLOAT or almost total incompability with old apps.


I really don't think it's going to be that bad concidering that memory in a Windows environment is already virtualized.  Also, Win64 is already running on IA64 machines.  Win32 apps are slower than slow mainly because the Itanium is emulating the IA32 ISA.  I expect that Intel will perk that up in the future.  As for code bloat, I can't say;  I've not had opportunity to survey an IA-64 machine.

Quote

I think we are at a nexus of computing, where Amiga Inc.'s fortunes could literally change overnight.


I think that if any fortunes were to change over night, it would be Linux.  Linux seems to be comming into it's power curve.
Title: Re: CPU Instructions Q.
Post by: JetRacer on March 18, 2003, 10:44:28 PM
> I think that if any fortunes were to change over night, it would be Linux. Linux seems to be comming into it's power curve.

I think Linux will eat custom buissness applications alive and then burp, no doubt about that.

Linux in our homes is another matter. It's a mess. Atleast for new users and non-nerds. If you want to replace something because it just don't fit your personal requirements, then you are confronted with a long list of options. And there is simply no way a newbie would be able to install any type of Linux distro. No way in hell.

Don't get me wrong, I use Redhat alot and it's great. But without a friend helping me out from time to time I'd be lost. And I'm a geek(!). It's the direct opposite of f.ex. the Amiga. The AmigaOS allowed people to learn no matter their current level of knowledge.
Title: Re: CPU Instructions Q.
Post by: Karlos on March 19, 2003, 02:37:00 PM
Don't panic ;-)

A PowerPC opcode is 4 bytes. The instruction set is orthogonal, very few instructions require more than one 4-byte word and when they do its a 4-byte word also.
Before anyone panics about code size, that 32-bit opcode can contain 3 register specifications (or even 4 for the madd instructions) as arguments. So an expression such as add. r3, r2, r5 has the three arguments encoded in the instruction.
The assignment of bits in a PowerPC instuction often contains implicit data. I may be wrong about this particular example, but the load/store commands that take 16-bit offsets actually have the offset in the 4 byte instruction word itself.
The result is that PowerPC code is not that bloated. For example, consider a very complex 68K addressing mode can increase the length of a simple, 16-bit word move instruction to up to 11 words!
Title: Re: CPU Instructions Q.
Post by: Atheist on March 19, 2003, 03:49:33 PM
Hi Karlos,

So, do you think a 64 bit CPU would need 8 bytes of ram per stored instuction, and/or 8 bytes on a disk?

AmigaOne! Where do you want to go today?  :-D  :-D
Title: Re: CPU Instructions Q.
Post by: Karlos on March 19, 2003, 04:06:17 PM
Quote

Atheist wrote:
Hi Karlos,

So, do you think a 64 bit CPU would need 8 bytes of ram per stored instuction, and/or 8 bytes on a disk?

AmigaOne! Where do you want to go today?  :-D  :-D


Not necessarily. I can see there is some confusion on what exactly a N-bit architecture means. A 32-bit system does not have to have 32-bit opcodes. A 68020 is a 32-bit processor, but the opcodes are still 16-bit.
The PowerPC is a RISC architecture and uses an orthogonal 32-bit instruction set because it simplifies the hardware design (a common RISC aim), which allows fewer transistors, higher speeds etc.

The big thing with 64-bit technology is a move to full 64-bit addressing capability rather than instruction size.

For example, x86 has had both 64-bit data bus and general purpose registers since the Pentium2 generation. As such, they can perform 64-bit integer arithmetic without software assistance, just like the 68040 can do a full 32x32 bit->64 bit multiplication (but uses two 32-bit regs to hold the result).

Despite the support for 64-bit datatypes, these are still classed as 32-bit CPUs. The physical (non virtual) pointers they use are still 32-bits which means that the CPU can only access a 4Gb physical address space. MMUs perform physical to logical mappings that expand that address space to something like 56-bits on a 603e.

The true 64-bit generation CPU's allow a full 64-bit physical address (ie all bits of the register used to hold a pointer are used) and have a full 64-bit address bus capability.

There is no need to increase the instruction word size. However, a full address specification will require 8 bytes, as you say.

There may be cases of 64-bit opcodes that actually pack several instructions into one 64-bit word. This is the so called VLIW architecture (Very Long Instruction Word) that intel has been researching as the next big thing...