From: user5857@newsgrouper.org.invalid   
      
   Paul Clayton  posted:   
      
   > On 1/28/26 10:34 AM, John Dallman wrote:   
   > > In article <10lbcg1$3uh8h$1@dont-email.me>, paaronclayton@gmail.com (Paul   
   > > Clayton) wrote:   
   -----------------   
   >   
   > Would the Intel-64 have been assembly compatible with AMD64? I   
      
   Andy Glew indicated similar but not exact enough.   
   Andy also stated that MicroSoft forced Intel's hand towards x86-64.   
      
   > would have guessed that not just encodings would have been   
   > different. If one wants to maintain market friction, supporting   
   > the same assembly seems counterproductive.   
      
   It was, in essence, the control register model, the nested paging,   
   and other insundry non ISA components.   
   >   
   > > This was crazy from the network externalities point of view. It was an   
   > > anti-competitive move, requiring software vendors to do separate builds   
   > > for Intel and AMD, hoping that they would not bother with AMD builds.   
   >   
   > Cooperating with AMD to develop a more sane encoding while   
   > supporting low overhead for old binaries would have been better   
   > for customers (I think). However, doing what is best generally   
   > for customers is not necessarily the most profitable action.   
      
   Yes, imaging Custer (Intel) and AMD (Sioux) sitting down together   
   and making optimal battle plans for Little Big Horn battle to come.   
      
   > > Microsoft killed this idea, by refusing to support any such   
   > > Intel-specific 64-bit x86. They could not prevent Intel doing it, but   
   > > there would not be Windows for it. Intel had to climb down.   
   >   
   > Which was actually a sane action not just from the hassle to   
   > Microsoft of supporting yet another ISA but the confusion of   
   > users (Intel64 and AMD64 both run x86-32 binaries but neither   
   > Intel64 nor AMD64 run the other's binaries!) which would impact   
   > Microsoft (and PC OEMs) more than Intel.   
   >   
   > >> I do not think assembly language considered the possible effects of   
   > >> memory order model. (Have all x86 implementations been compatible?   
   > >> I think the specification changed, but I do not know if   
   > >> compatibility was broken.)   
   > >   
   > > In general, the assembly programmer is responsible for considering the   
   > > memory model, not the language implementation.   
   >   
   > Yes, but for a single-threaded application this is not a factor —   
   > so such would be more compatible. It is not clear if assembly   
   > programmers would use less efficient abstractions (like locks) to   
   > handle concurrency in which case a different memory model might   
   > not impact correctness. On the one hand, assembly is generally   
   > chosen because C provides insufficient performance (or   
   > expressiveness), which would imply that assembly programmers   
   > would not want to leave any performance on the table and would   
   > exploit the memory model. On the other hand, the assembly   
   > programmer mindset may often be more serial and the performance   
   > cost of using higher abstractions for concurrency may be lower   
   > than the debugging costs of being clever relative to using   
   > cleverness for other optimizations.   
   >   
   > >> In addition to the definition for "assembly language" one also   
   > >> needs to define "architecture".   
   > >   
   > > Actually, the world seems to get on OK without such clear definitions.   
   > > The obscurity of assembly language tends to limit its use to those who   
   > > really need to use it, and who are prepared to use a powerful but   
   > > unforgiving tool.   
   >   
   > Yes, the niche effect helps to avoid diversity of meaning across   
   > users and across time. I suspect jargon also changes less rapidly   
   > than common language both because there is less interaction and   
   > there is more pressure to be formal in expression.   
   >   
   > >> Intel has sold incompatible architectures within the same design   
   > >> by fusing off functionality and has even had different application   
   > >> cores in the same chip have different instruction support (though   
   > >> that seems to have bitten Intel).   
   > >   
   > > Well, different ISA support in different cores in the same processor   
   > > package is just dumb[1]. It reflects a delusion that Intel has suffered   
   > > since at least the late 1990s: that software is specific to particular   
   > > generations of their chips, and there's a new release with significant   
   > > changes for each new generation. Plenty of Intel people know that is true   
   > > for motherboard firmware, but not for operating systems or application   
   > > software. But the company carries on behaving that way.   
      
   One can still buy a milling machine built in 1937 and run it in his shop.   
   Can one even do this for software from the previous decade ??   
      
   MS wants you to buy Office every time you buy a new PC.   
   MS, then moves all the menu items to different pull downs and   
   makes it difficult to adjust to the new SW--and then it has the   
   Gaul to chew up valuable screen space with ever larger pull-   
   down bars.   
      
   Is it any wonder users want the 1937 milling machine model ???   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)