On Tuesday, July 31, 2018 at 10:06 AM, Paul Koning wrote:
> > On Jul 31, 2018, at 12:36 PM, Mark Pizzolato wrote:
> >
> > ...
> >> Interesting, and not too surprising. Given that, it may be useful to
> >> use a recent GCC which supports LTO -- Link Time Optimization.
> >> That's a scheme that
On 31-Jul-18 13:46, Paul Koning wrote:
> No, but thanks for that pointer. The paper I was thinking about is
> listed in the references:
> Xi Wang, Haogang Chen, Alvin Cheung, Zhihao Jia, Nickolai Zeldovich, and M.
> Frans Kaashoek. 2012a. Undefined behavior: What happened to my code? In
>
I'm going to send this once here -- please take any follow up off line to
me privately. I don't want to seed a discussion of goodness or badness of
different compilers. This is purely as an FYI for those that may not be
aware.
*Comments are my own and do not neccessarily represent official
> On Jul 31, 2018, at 1:08 PM, Timothe Litt wrote:
>
> On 31-Jul-18 12:41, Paul Koning wrote:
>>
>>
>> One thing that happens with newer compilers is that they take more advantage
>> of opportunities offered by the letter of the standard. If you do something
>> that is "undefined", the
On 31-Jul-18 12:41, Paul Koning wrote:
>
>
> One thing that happens with newer compilers is that they take more advantage
> of opportunities offered by the letter of the standard. If you do something
> that is "undefined", the compiler can do with that whatever it wants to. If
> you have code
> On Jul 31, 2018, at 12:36 PM, Mark Pizzolato wrote:
>
> ...
>> Interesting, and not too surprising. Given that, it may be useful to use a
>> recent
>> GCC which supports LTO -- Link Time Optimization. That's a scheme that
>> allows
>> whole-program optimization, rather than the normal
> On Jul 31, 2018, at 12:27 PM, Mark Pizzolato wrote:
>
> ...
>
>> I'm not sure where SimH stands on compiler optimizations - you can always
>> try
>> compiling with the highest optimization level your compiler supports. But
>> you may have to report some bugs...
>
> The normal build
On Tuesday, July 31, 2018 at 9:18 AM, Paul Koning wrote:
> > On Jul 31, 2018, at 11:55 AM, Henry Bent wrote:
> >
> >
> > On 31 July 2018 at 11:49, Timothe Litt wrote:
> >
> > On 31-Jul-18 10:08, Paul Koning wrote:
> >>> On Jul 31, 2018, at 9:33 AM, Robert Armstrong
> >>> wrote:
> >>>
> >>>
>
On Tuesday, July 31, 2018 at 5:48 AM, Timothe Litt wrote:
> On 31-Jul-18 01:31, Jeremy Begg wrote:
> > The license wouldn't be an issue if the SET CPU MODEL command worked.
>
> It looks as though it works - but not as you (or I) expect. It defines the
> SimH model - which is mostly I/O devices.
> On Jul 31, 2018, at 11:55 AM, Henry Bent wrote:
>
>
> On 31 July 2018 at 11:49, Timothe Litt wrote:
>
> On 31-Jul-18 10:08, Paul Koning wrote:
>>> On Jul 31, 2018, at 9:33 AM, Robert Armstrong
>>> wrote:
>>>
>>>
>>> FWIW, this may also say something about the quality of the code
On 31 July 2018 at 11:49, Timothe Litt wrote:
>
> On 31-Jul-18 10:08, Paul Koning wrote:
>
> On Jul 31, 2018, at 9:33 AM, Robert Armstrong
> wrote:
>
>
> FWIW, this may also say something about the quality of the code generation
> in gcc for ARM vs x86 processors, or it may even say something
On 31-Jul-18 10:08, Paul Koning wrote:
>
>> On Jul 31, 2018, at 9:33 AM, Robert Armstrong wrote:
>>
>> FWIW, this may also say something about the quality of the code
>> generation in gcc for ARM vs x86 processors, or it may even say
>> something about the relative efficiency of those two
> On Jul 31, 2018, at 9:33 AM, Robert Armstrong wrote:
>
>> My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a
>> i7-3770 CPU @ 3.40GHz (which is starved for RAM), SIMH/VAX on a VM
>> running on it clocks in at about 34.6 VUPS. I have a i5-3470 @ 3.2Ghz
>> and SIMH runs at
>My Raspberry Pi 2 clocks in at about 1.6 VUPS, my ESXI host is a
>i7-3770 CPU @ 3.40GHz (which is starved for RAM), SIMH/VAX on a VM
>running on it clocks in at about 34.6 VUPS. I have a i5-3470 @ 3.2Ghz
>and SIMH runs at about 31.6 VUPS
FWIW, this may also say something about the quality
Hi,
Thanks all for your further comments, and I stand corrected on the nature of
the calculations performed to set up an SSH session. I think at this point
I'll give up on the SSH and rework my remote access to the machine.
>> The license wouldn't be an issue if the SET CPU MODEL command
The code that was posted is inappropriate, and should be removed from
the list archives.
VMS has not been abandoned, and this group is not in the business of
stealing IP.
There is a hobbyist program, still available, for non-commerical
licenses. Legitimate PAKs can be obtained there.
For
On 31-Jul-18 01:31, Jeremy Begg wrote:
>
> The license wouldn't be an issue if the SET CPU MODEL command worked.
It looks as though it works - but not as you (or I) expect. It defines
the SimH model - which is mostly I/O devices.
Your issue is with the SYS_TYPE register, which lives at location
A couple of comments.
On the issue of starting up, I guess it depends on what kind of error
you get when. But in general, I would agree with Zane. Don't redirect
stdin. Give the config file as as argument instead. I would say that is
the canonical way of doing it.
Speedwise, 12 times faster
18 matches
Mail list logo
