Re: [Simh] simh on RaspBerry Pi

2016-02-15 Thread Thomas Merritt

> On Feb 15, 2016, at 8:37 AM, Johnny Billquist  wrote:
> 
> On 2016-02-15 16:15, Paul Koning wrote:
>> 
>>> On Feb 15, 2016, at 9:01 AM, Wilm Boerhout  wrote:
>>> 
>>> Will Senn schreef op 15-2-2016 om 14:26
>>> 
>>> [snip]
>>> 
 Are you documenting the setup process for your endeavors, or just blogging 
 about the result? I think it would be interesting to see how you clustered 
 those Pi Vaxen as much as to know it was possible. I've got a few Pi 
 around looking for something to cluster around...
>>> There are three parts to a successful setup:
>>> 
>>> 1. Since each Pi has only one Ethernet interface, make sure you use a
>>>   wired connection (wireless isn't real Ethernet)
>> 
>> Well, Wireless is 802.11 which indeed isn't 802.3 / Ethernet.  But that's 
>> not really relevant.  The question is whether it uses Ethernet addressing 
>> and offers an Ethernet-compatible MAC layer API, and 802.11 certainly does.  
>> You can run SimH Ethernet just fine over a wireless LAN.  I've run PDP11 
>> SimH that way with no problems.
> 
> Actually, I have run into problems. The broadcast domain, as well as the 
> Unicast have slight differences to Ethernet, which makes it sometimes fail in 
> subtle ways.
> Having a second mac address on a WiFi interface, one that is used by simh, 
> though tun/tap, does not work that well with WiFi. Unfortunately.
> 
> I've definitely had problems keeping it working under OS X at least. And I'm 
> pretty sure I've read of others having the same problem.
> 
>   Johnny
> 
> 
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

This is a feature of 802.11.  The packet format over the air for 802.11 has two 
MAC addresses in it to in theory enable bridging.  One for the radio and one 
for the sender.  Most 802.11 firmware just stuffs the radio's MAC address in 
both and ignores the MAC address in the original frame when sending, and when 
receiving the senders radio MAC address is used in the frame propagated to the 
computer by the adapter.  The result is that everything is sent as if from the 
host and not the VM and replies are delivered back to the host and not the VM.  
This can be worked around in the hypervisor as VirtualBox does for IPv4 and to 
some degree IPv6.  But don't expect a SimH machines to be able to communicate 
over WiFi without a lot of work in SimH’s networking implementation.

-- TJ
___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Re: [Simh] VAX/VMS

2016-02-17 Thread Thomas Merritt
That is a pretty Intel centric view of history.  The original architecture was 
developed by AMD.  The architecture was initially called x86-64 by AMD and was 
renamed right before the public launch to AMD64.  SUSE was involved in the 
development of the gcc port and linux port, didn’t wan’t to take the risk of of 
changing all of the x86_64 references to amd64, so the x86_64 name persists.  
The first Intel chips got a number of items wrong that were never issues on the 
released AMD chips.  The NX bit was not in all of AMD’s development spins, but 
was discussed publicly on the x86_64 mailing list prior to the release of the 
first Athlon64 chips.  When Intel later released their first x86_64 compatible 
chips they did not include the NX bit and would not run Linux correctly.  
Microsoft, having early access to the Intel chips, did not have issues with the 
64-bit version of Windows as I recall.  Both Intel and AMD have made 
enhancements over the years to the AMD64 (ne x86_64) architecture.  The AMD and 
Intel flavors of virtualization support are different, AMD’s Pacifica is well 
thought out, Intel took four iterations on Virtualization to get to what they 
have today.  Because of the quick response on the Intel side, they were able to 
stay competitive in the marketplace.  If they had continued to pursue the 
Itanium route for 64-bit, they would ultimately have lost the market to AMD.  
Fortunately for Intel, they included enough AMD compatibility to remain 
competitive.  They had huge advantages on the semiconductors side of the house, 
that has allowed them to be the dominate player that they are today.

— TJ

> On Feb 16, 2016, at 2:44 PM, Clement T. Cole  wrote:
> 
> Depends on how you look at it,  AMD did developed an early 64 bit extensions 
> on to the 32 bit ISA. But that was over 10 years ago and I was not there at 
> the time.   IMO thankfully when Core/INTEL*64 was developed much of it made 
> to be the same in the desire to keep user binaries to run.   Since that time 
> Intel has taken and continues to extend the ISA. Simply put, INTEL*64 is 
> different - there are whole sections of the ISA that are not implemented on 
> all processors (even at Intel). For instance Intel's Phi brings in a number 
> of new instructions.  INTEL*64 is the official name (trademark name) for the 
> ISA (although some folks refuse to acknowledge that fact). 
> 
> Also in the case of privileged ISA features there are some significant 
> difference which the OS's have to handle.  For instance the VT subsystems 
> have some differences.
> 
> As Tim points out the real cost of compatibly is the architectural tests 
> suites and effort to ensure that things just work across the board.  In the 
> case of x86 it's even more difficult then just the instructions and BIOS 
> because it means whole HW sections have to be made virtual also so that old 
> code (like ones for DOS) do keep working.  
> 
> Similarly, Regardless of which Intel produced processor for that ISA is the 
> output target,
> Intel's compilers generate code for the INTEL*64 ISA and perform optimization 
> for same.  When user mode binaries are run on non-intel manufactured 
> processors they should "just work" if the others manufactures have 
> implemented equivalent functionality (There is no truth to the sometimes 
> stated comment that Intel's compilers check for non-intel manufactured and do 
> bad things).  That said the Intel development suite does not do specific 
> optimizations for non intel manufactured processors but they do make an 
> attempt to ensure things execute correctly. 
> 
> The neutral term is x86_64 which does not acknowledge either AMD or Intel.  
> But in print, I am fairly certain that the ISA's trademarked name is INTEL*64 
> when referring to that ISA.  
> 
> Sent from my iPad
> 
>> On Feb 16, 2016, at 5:02 PM, Rhialto  wrote:
>> 
>>> On Tue 16 Feb 2016 at 11:25:37 -0500, Clem Cole wrote:
>>> Unless you are using a cell phone, I'm willing to bet that you are typing
>>> your messages on a INTEL*64 architecture system, even if the processor is
>>> not made by Intel.
>> 
>> Was the 64-bit mode not designed by AMD? I'm typing this on NetBSD/amd64
>> after all...
>> 
>> -Olaf.
>> -- 
>> ___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
>> \X/ rhialto/at/xs4all.nl-- 'this bath is too hot.'
> ___
> Simh mailing list
> Simh@trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh

___
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh