Before I touch again the current topic ( manufacturing process [I have a preview for you though of my reply: good and valid arguments, you do have something in your hands it seems..., but watch out I am the kind of opponent that when he loses an argument he takes the opponents' arms off...
j/k, aside the Star Wars reference I am liking this argument as you're trying to make a point prooceeding step by step giving me rational points and I like it
] )... I have a point I want to touch again ( please read the whole message )...
The APUs...
Are they micro-coded or not ? Can they be also micro-coded ( cna they run micro-code ?
The first question is dependent on the second one because the answer would be "it depends".
The second question would be answered by me with a "Yes" for various reasons...
The first is one of the more specific hints the patent gives us:
[0144] In lieu of an absolute timer to establish coordination among the APUs, the PU, or one or more designated APUs, can analyze the particular instructions or microcode being executed by an APU in processing an apulet for problems in the coordination of the APUs' parallel processing created by enhanced or different operating speeds.
Why am I thinking about micro-code ?
Well we know some things:
1) a software cell can run on any processor in the network
2) the APUs share a common ISA
3) the APU are "preferrably" SIMD based ( Integer and FP [1 FMAC and 1 FDIV in each of the FP Unit in the APU ?] )
4) the number of FP units in the APU can change to a higher and also lower value than he regular 4 FP Units/APU ( same is worth for the integer side )...
I have two ideas regarding this ( let's think about runnign a 4-way parallel MADD [SIMD... oh and btw, who knows if in the ISA of the APU there are not scalar instructions like it happened with SSE 1-2] ):
1.) First the problem of running the said 4-way parallel MADD on APUs with fewer FP Units than the standard 4 FP Units/s as the current specs prefer...
2.) Second the problem of running that instruction in APUs with more than 4 FP Units...
First problem ( 1.) ):
the APU that receives such instruction would have a micro-code that would execute said instruction even with a smaller number of FP Units than expected... Looping back might be key to this...
Second problem ( 2.) ):
This could be solved by adding NOPs to the instruction stream since this is not an instruction designed specifically to run on slower machines ( processing power wise ) or maybe the PU might send a bigger workload to the APU... after all the software cell is processed by the APUs accorind to how the PU is instructing them to...
The PU schedules and orchestrates the processing of data and applications by the APUs.
Or maybe the APU can issue a new instruction with the free FP Units, but if the supposed 5th FP Unit can work independently from the other 4 why cannot the other 4 work independently from each other ?
Sorry If I am being a bit messy with making my argument, but I am quite sleepy ( still wanted to post, have thought about this all evening
)...
Mine is an implementation issue... we have APUs that are generally SIMD processor ( for both Integer and Data ) and we say this:
Since all computing resources have the same basic structure and employ the same ISA, the particular resource performing this processing can be located anywhere on the network and dynamically assigned.
But it is also said that an APU can have more than 4 FP or Integer Units or less than 4 depending on processing needs... still we keep the same ISA...
how do you process a 4-way SIMD operation like a vector MADD if you are allowed to have a variable amount of Execution Units ?
This is the issue... above I tried to give some quick and dirty "possible" implementation decisions ( although I apologize for maybe the poor wording ), but there is surely more ground to cover on this...
In a still related topic, don't you love the software cells structure and the incorporation of routing information in the header ( and having both data and instructions )...
[0121] The structure of software cells 102 is illustrated in FIG. 23. As shown in this figure, a software cell, e.g., software cell 2302, contains routing information section 2304 and body 2306. The information contained in routing information section 2304 is dependent upon the protocol of network 104. Routing information section 2304 contains header 2308, destination ID 2310, source ID 2312 and reply ID 2314.
each of these ID's contains a network address...
uhm... destination ID could be Destination Address, source ID could be Source Address and reply ID ( from what I read ) could be the next hop, as we read here:
The destination ID includes a network address. Under the TCP/IP protocol, e.g., the network address is an Internet protocol (IP) address. Destination ID 2310 further includes the identity of the PE and APU to which the cell should be transmitted for processing. Source ID 2314 contains a network address and identifies the PE and APU from which the cell originated to enable the destination PE and APU to obtain additional information regarding the cell if necessary. Reply ID 2314 contains a network address and identifies the PE and APU to which queries regarding the cell, and the result of processing of the cell, should be directed.
Implementing a routing protocol like RIPng ( no sense using RIPv2 as IPv4 based and RIPng should be backwards compatible and most RIPv2 routers will still process a RIPng message or try to
I am talking based on experience... plus the RIP specs in that RIPv2 FRC are not clear on the RIP version 3 or greater subject ) or OSPF for IPv6 could be implemented quite nicely with this software cell structure...
In the data portion we can store the rest of the header including TCP/UDP etc...
"Wait" you will say "what about layer 2 where do you put the MAC address info ?" Well it is not an uncommon practice in IPv6 to base the 128 bits address of a network interface on the MAC address, using the MAC address as part of the IPv6 address...
We could encode layer 2 and layer 3 informations in simple IPv6 addresses...
I do not know yet ( maybe some of the images of the patent will give me a better understanding ), but I do think that the network address used in those "ID's" is effectively an IPv6 address: good for a forward lookin g architecture like CELL and that makes sense judging by a partnership Sony started with CISCO related to some IPv6 and IPv4 work ( including a hybrid protocol, IIRC)...
128 bits addresses would fit quite nicely in those 128 bits registers the APUs have
This architecture is indeed flexible... since we already have tons of software routers around why not choosing one that uses the "CELL architecture" there is basiclaly support in HW