Yeah, I think I had an older copy. Pulled the latest down and it built cleanly other than the MAX redefinition warning and the "openbsd thinks you're a moron for using strcpy()" warning.
All appears well as Sampsa can talk to HECnet via a bridge to me tunneled over OpenVPN. Ugly, but functional. :)
-brian
On 8/10/2012 6:54 AM, Johnny Billquist wrote:
Brian, could you verify that you have the latest version? I did some work to try and get rid of warnings a while back, and even though I'm sure some issues might be because of 64 bit issues, I would have expected some of the warnings you reported to have been fixed already...
Johnny
On 2012-08-09 21:00, Brian Hechinger wrote:
I'm trying to get the bridge built on OpenBSD 5.1 64-bit but it keep
segfaulting. Anyone ever get this working?
# cc -O2 -Wall -o bridge bridge.c -lpcap
bridge.c:65:1: warning: "MAX" redefined
In file included from /usr/include/netdb.h:90,
from bridge.c:32:
/usr/include/sys/param.h:191:1: warning: this is the location of the
previous definition
bridge.c: In function 'add_bridge':
bridge.c:241: warning: implicit declaration of function 'inet_aton'
bridge.c:263: warning: format '%d' expects type 'int', but argument 2
has type 'char *'
bridge.c:263: warning: format '%d' expects type 'int', but argument 3
has type 'char *'
bridge.c: In function 'add_service':
bridge.c:276: warning: format '%s' expects type 'char *', but argument 3
has type 'struct BRIDGE *'
bridge.c: In function 'dump_data':
bridge.c:524: warning: implicit declaration of function 'inet_ntoa'
bridge.c:531: warning: format '%s' expects type 'char *', but argument 4
has type 'int'
bridge.c: In function 'main':
bridge.c:564: warning: unused variable 'port'
bridge.c:561: warning: unused variable 'len'
/tmp//cc69aRp2.o(.text+0x934): In function `add_bridge':
: warning: strcpy() is almost always misused, please use strlcpy()
# cp bridge /var/bridge/
# cd /var/bridge/
# ./bridge 4711
Adding router ''local''. 00000000:0
Adding router ''sampsa''. 0afc2a0a:4711
Adding DECnet bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding DECnet bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Adding LAT bridge local.
Trying to match local
Matching against: local
Found match: local == local
Adding LAT bridge sampsa.
Trying to match sampsa
Matching against: local
Matching against: sampsa
Found match: sampsa == sampsa
Host table:
Segmentation fault (core dumped)
-brian
What I meant is that the os fit was done in firmware. Not, like the VAX, where the instruction set was designed to match demands from the os. IIRC the queue instructions aren't part of the Alpha instruction set.
On or off topic? It's Digital Lore, right :-)
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 16:29:00
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand
internal knowledge of VMS and where it was headed / what it's customers
needed. I had a pre-release AXP Architecture Handbook which would
confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 10/08/2012 3:10 PM, Paul_Koning at Dell.com wrote:
On Aug 10, 2012, at 4:07 PM, <hvlems at zonnet.nl>
wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
I don't think that's accurate.
Most operating systems are not closely tied to a specific platform. And in the case of VMS, the Alpha architecture had some specific attributes that were meant to make porting VMS easier.
I agree. Alpha architecture was done with a posteriori and first-hand internal knowledge of VMS and where it was headed / what it's customers needed. I had a pre-release AXP Architecture Handbook which would confirm, if I could lay my hands on the tree ware.
But this is OT, I suppose.
Phil M
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 08/10/2012 05:21 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
Interesting! I didn't know that. Thanks for the info!
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
On Aug 10, 2012, at 5:06 PM, Dave McGuire wrote:
On 08/10/2012 04:29 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
No, but you can enable frame pointers if you need them. Depending on the debugger, you may not need them. For example, MIPS seems to have them in theory, but in practice there is no reason to use them (except if a function calls alloca() in which case GCC forces a frame pointer for that one function).
paul
On 08/10/2012 04:29 PM, Paul_Koning at Dell.com wrote:
Try adding -fomit-frame-pointer; that will free up a register, which
is pretty important on register-starved architectures such as x86 and
x86_64. (depending on your -O<n> level, it might already be turned on
though)
According to the manpage, that's already the default as of GCC V4.6. I'm currently doing some tests with GCC 4.7.0, the latest release.
Cool. But...the default? With no frame pointers, debugging is pretty
difficult. I assume it's only enabled with -O[n], and disabled with
-g[xxx]?
-Dave
--
Dave McGuire, AK4HZ
New Kensington, PA
oddly enough the Alpha compiler on NT was HORRIBLE... And it had DEC strewn all over its copyrites so I suspect it wasn't a 100% Microsoft thing.. Naturally by the time you could compile with O2 and have the exe actually run properly support for the Alpha was dropped in the Compaq HP acquisition.
Even the leaked NT source complained bitterly about the Alpha C compiler..
Oh well it's all ancient history now.
On Fri, Aug 10, 2012 at 4:07 PM, <hvlems at zonnet.nl> wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
The reason support for Windows was dropped for all platforms other than IA32 and IA64 indicates that it is too costly if not impossible to engineer.
After all these years Windows settled nicely on IA32.
What Microsoft probably lacks is DEC's compiler architects. Those guys live with Intel now and performance these days is very much their line of business.
It wouldn't surprise me if Intel and Microsoft did do a little bit of joint engineering since 1998.
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 13:29:06
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 10:51 AM, hvlems at zonnet.nl wrote:
> Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
> Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
But VMS had the advantage that it and the processor (VAX) that ran it
were designed in concert. x86 architecture and Windows are more a case
of being cobbled together iteratively and separately.
--
"Worry is a misuse of imagination." -- Some Guy Called Dan Zadra
On 2012-08-10 22:07, hvlems at zonnet.nl wrote:
Correct, Windows started off on four platforms so the intimacy of VMS with the VAX was just not there. But VMS was a lot farther away from Alpha too.
The reason support for Windows was dropped for all platforms other than IA32 and IA64 indicates that it is too costly if not impossible to engineer.
I don't think that technical issues was the problem. There just wasn't enough of a business case to make it profitable. You don't put the effort into it, if it don't give atleast the money back...
What has this to do with HECnet, or DECnet...? :-)
Johnny
After all these years Windows settled nicely on IA32.
What Microsoft probably lacks is DEC's compiler architects. Those guys live with Intel now and performance these days is very much their line of business.
It wouldn't surprise me if Intel and Microsoft did do a little bit of joint engineering since 1998.
-----Original Message-----
From: Phil Mendelsohn <phil at rephil.org>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 13:29:06
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
On 10/08/2012 10:51 AM, hvlems at zonnet.nl wrote:
Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
But VMS had the advantage that it and the processor (VAX) that ran it
were designed in concert. x86 architecture and Windows are more a case
of being cobbled together iteratively and separately.
Jordi Guillaumes i Pons
Barcelona - Catalunya - Europa
El 10/08/2012, a les 22:06, <Paul_Koning at Dell.com> va escriure:
I suppose I could try llvm for Linux, I'm not sure if that exists on a Mac. But gcc is what I know. And it seems to do a pretty good job optimizing. For one thing, a lot of people (a number of them Intel employees) have worked hard on the Intel back end.
Actually, LLVM is the default compiler in the current version of MacOS :)
You could also try the Intel compiler for Linux. It is said it optimizes better than GCC, but I have not benchmarked it myself.
paul
On Aug 10, 2012, at 3:58 PM, <hvlems at zonnet.nl>
wrote:
Is gcc the only option you've got Paul?
Gcc must satisfy a lot of terget platforms, may be optimal gets defined differently?
-----Original Message-----
From: <Paul_Koning at Dell.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 18:37:47
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
Yes, the makefile sets the optimize flags. It tells it to optimize pretty hard, but I'm redoing some tests with a later version. I'm also going to try (first time I've done that) profile directed optimizing.
The simh code at one point used inline, but not any longer. It may be relying on recent compilers to do that automaticallly, I'll find out.
paul
On Aug 10, 2012, at 11:51 AM, <hvlems at zonnet.nl>
<hvlems at zonnet.nl> wrote:
Paul, so the makefile sets the compiler flags, right? So it might be worth figuring out how much effort the compiler puts in optimizing its output.
Windows is a relative of vms, an ugly cousin but still family. Its growth is stunted, Windows 7 is the fifth version after W 3.5. VMS grew a lot faster, with more (end user) functionalty, more stability during its first two decades.
Even then Windows 5.1 (aka XP) is stable and useful. Vista wasn't then again VMS 6.1 wasn't that mature either...
Hans
-----Original Message-----
From: <Paul_Koning at Dell.com>
Sender: owner-hecnet at Update.UU.SE
Date: Fri, 10 Aug 2012 14:28:45
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
In my case, gcc with the default makefile. I don't use VC (or the OS it runs on) unless serious force is applied...
paul
On Aug 10, 2012, at 3:02 AM, <hvlems at zonnet.nl>
wrote:
How was simh compiled? I used Visual C and the difference between running the compiler with optimization on or off made quite a difference for the generated code. And gcc might compile even faster codefiles.
Hans
-----Original Message-----
From: Sampsa Laine <sampsa at mac.com>
Sender: owner-hecnet at Update.UU.SE
Date: Thu, 09 Aug 2012 23:07:24
To: <hecnet at Update.UU.SE>
Reply-To: hecnet at Update.UU.SESubject: Re: [HECnet] AXP Emulation
Why is SIMH so slow though?
As far as I can understand, one MIPS is roughly one VUPS, correct?
So how come I get 14 VUPS on the same host running SIMH whilst my Hercules install peaks at 180?
Are the architectures that different (obviously they are) or what is it?
Sampsa
