Itanium….

This isn’t virtual, but rather the real deal. I scored an HP zx2000.

HP Itanium

My HP zx2000

Just got it out of the box, I had to remove the funky sides to get it under my desk… And I’ve just installed Windows XP onto it now. My first observation is that the included DVD drive from HP, the HL-DT-ST GDR8160B has got to be one of the slowest drives I’ve dealt with in a while. And kinda finicky as the first attempt at installing XP failed with all kinds of errors, while a swift kick and a power cycle got the thing running. And let’s see it in action..

This thing likes to tell you over and over that it’s the 64bit version. It may look like XP but it’s not the 32bit version. It is however much like the x86_64 version with no NTVDM, no WOW. But worse, no Virtual PC. It can run i386 win32 exe’s but at a performance penalty. I saw mention that the Itanium C compiler can be found in the November 2001 Platform SDK, so I downloaded that, and installed it.

It’s slow.

It’s annoyingly slow.

All that talk of EPIC, and moving the complexity to the compiler isn’t a joke. Did I mention, it is *SLOW*? I thought it was running an i386 version of the compiler but the taskman didn’t show any stars next to the processes so I’m assuming not, but I’m not sure. I also am assuming that the November 2001 SDK is timed with the “Windows 2000 Advanced Server Limited Edition” for the Itanium. So I figured for a quick test, I’d build some dungeon… Except the f2c interpreter broke in some strange manner. I’d first think it’s something to do with integer sizes, but it worked on x86_64.. So I cheated, used the i386 version of f2c, and built the library and dungeon. Also I found out about this flag, /As32 which builds exe’s in the 32bit address space. f2c will run once it’s built like that. And although compiling f2c takes forever, once built it is FAST.

It worked. The exe is over 900kb! Without at doubt when they called it EPIC they meant the compiler speed, and exe size. For the crazy, you too can play zork on your Itanium here.

And yes my attempt at building SDL bombed too. But I’ll have to spend more time with the box.

SIMH benchmark numbers…

I have to admit, I’m really surprised. In the past Visual C++ had been a clear winner every time I’d checked performance vs Gcc. And the tide seems to have really turned under Windows 7 x64. While not a massive lead, the winner after all these iterations of my simh benchmark was Gcc 4.5.2 for x86_64.

Just in the same fashion here, it seems that on some platforms -O1 is faster then -O2, and you really won’t find out until you run some comparisons.

gcc version 3.4.5 (mingw-vista special r3)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 23
This machine benchmarks at 21739 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 20
This machine benchmarks at 25000 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
15.33333333333333
Dhrystone(1.1) time for 500000 passes = 16
This machine benchmarks at 31250 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 15
This machine benchmarks at 33333 dhrystones/second

gcc 02
12.33333333333333
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

gcc version 4.5.2 20101002 (prerelease) [svn/rev.164902 – mingw-w64/oz] (GCC)

gcc O0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second

gcc O1
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

gcc O2
12
Dhrystone(1.1) time for 500000 passes = 11
This machine benchmarks at 45454 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 12
This machine benchmarks at 41666 dhrystones/second

Microsoft (R) C/C++ Optimizing Compiler Version 16.00.30319.01 for x64

VC /Od /Bi0
21.33333333333333
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 21
This machine benchmarks at 23809 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 22
This machine benchmarks at 22727 dhrystones/second

VC /O2 /Ob2 /Oi
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

VC /O2
13.66666666666667
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second

Vc /Og /Ox
13
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80×86
VC /Og /Ox
13.33333333333333
Dhrystone(1.1) time for 500000 passes = 14
This machine benchmarks at 35714 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second
Dhrystone(1.1) time for 500000 passes = 13
This machine benchmarks at 38461 dhrystones/second

And this is on my laptop, an Intel Core i7 Q 720 running at 1.6Ghz with 4GB of ram & Windows 7 Home Premium.

Serweb 0.3

So a while back when I installed a copy of Windows NT 3.1, and put it on the internet, I looked high and low for a web server. Somehow I found this small web server, Serweb by Gus Estrella, which seemed to fit the bill. However one thing that I did notice after a while is that it had a tendency to crash, and it’d require manual intervention to hit an ‘ok’ dialog box. The other stumbling block, was that it was a Win16 application, and Windows NT 3.1 only supports a single WOW instance…. So running Serweb and Netscape always led to issues…

Then the other day, I actually found the source code to serweb! So the first thing I did was to remove the message box function that was preventing me from letting this thing ‘just run’. Well that was cool, but I wondered if this thing was from 1993, meaning it’s MFC dependencies shouldn’t be that involved it may even port to a Win32 application.

So with a few tweaks, mostly in the resource scripts, I was able to rebuild serweb as a win32 application! For the 2-3 people who care about this kind of thing, you can download it here.

I would suspect it’d run on the Dec Alpha or the MIPS, but I haven’t even tried to build it there, as I run NT 4.0 on both of those platforms, and I end up using the IIS that is available.

Serweb 0.3 on WindowsNT 3.1

Serweb 0.3 on WindowsNT 3.1

I do have to admit, I’m kinda surprised that Visual C++ 1.0 for Win32 could handle this… I’ve had pretty mixed results with it, but oddly enough converting a MFC Win16 to a Win32 MFC app seemed somewhat straight forward. It’s probably more so to Gus Estrella’s work then anything I did…!

Visual Studio 2010 just shipped

So many editions!!… I’m already confused. I think this is the last version to support the Itanium, as that platform is basically cooked.

Considering how lackluster and scarce they were at the launch I guess it’s not surprising.

Anyways It’ll be nice to fire up the x64 CLI tools, and not be told that the ‘release’ is infarct a beta…

Anyways, there is some details over at the MSDN site.. And a demo/eval download.

On the ‘cheap’ front, the express editions are also updated to the 2010 level. I’d recommend getting the ‘offline’ ISO image… That way you’ve got all the bits in one shot.

On the UNIX front, I found that on OpenSolaris, that the SunStudio is a free download. This includes SUN’s C/C++/Fortran (77/90/95) compilers.

I took a quick look at the SUN F77 compiler, and it’s certainly the UNIX one from the days of v7 as it behaves the same way… I guess that’s not too surprising.

Other then that, not a heck of a lot going on.

A quick follow up to building DLL’s

Another slight issue I’ve found with the SLiRP code, is that it expects to be able to call two functions (slirp_can_output and slirp_output). The snag here is that DLL’s expect to be SELF CONTAINED… So how can you have a DLL that needs to call functions from your program?

Void pointers!

So let’s make this more… involved.

dll.c

void (*bob)(int xy);

__declspec(dllexport) int hi(void)
{
(*bob)(12);
return 3;
}

__declspec(dllexport) void Register(void *p)
{
bob=p;
}

test.c

extern void Register(void *p);

void XX(int xy)
{
printf(“XX %d\n”,xy);
}

void main(void)
{
int j;
Register(XX);
j=hi();

printf(“%d\n”,j);
}

And let’s build it…

c:\temp\dll>cl /c /LD dll.c
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

dll.c

c:\temp\dll>link /DLL dll.obj
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

Creating library dll.lib and object dll.exp

c:\temp\dll>cl test.c dll.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
dll.lib

c:\temp\dll>test
XX 12
3

So as we can see, the main procedure runs the ‘register’ procedure to tell the dll that the ‘bob’ procedure will infact be XX. Now when the dll invokes it’s ‘hi’ function it can call the XX function from the exe. Now if I were a better programer, I’d use the DLLMain code to make sure that all my virtual void functions cause some kind of ‘readable’ panic message when called so you don’t get the default reaper… Because naturally if you run the dll code without the register function it’ll crash in a not so great manner.

But I’ll leave that as an exercise to the reader.

I’ve made some good progress on the SIMH thing, Ive got the non networked versions & the libpcap stuff building with Visual C++ 2008… I was thinking about using that 2010 RC but that just seems wrong…. But for now all I’ll have to do is apply this logic to the slirp dll, and get building the VC version for linking, and the Mingw version for actual operation….

Build a DLL

Well this is leading up to a new release of my SIMH projects. The issue that I’ve had with the SLiRP code (usermode NAT) is that it only works when built with GCC, and ONLY when you have no optimizations. Naturally you will loose all optimizations with SIMH if you build the entire project like that. And of course you cannot use Visual C++ to build SIMH, because while it’s faster they use different object files.

So while thinking about what a bummer it is, and how to try to debug SLiRP with Visual Studio, today I had a ‘better’ idea. Well ‘better’ in that I can do this way quicker.

Instead I’ll build SLiRP as a DLL, and have Visual C++ call that!

Ok, now that sounds crazy, but the first thing I’d need is a simple ‘test’ case. First let’s build a dll in MinGW. It took a bit of googling but then I found this super simple example.

dll.c

__declspec(dllexport) int hi(void)
{
return 3;
}

Ok, it doesn’t do that much, but you get the idea. Now we have to compile this with MinGW.

gcc -c dll.c
gcc -shared -o test.dll dll.o

Ok, now this will first compile the C file into an object file, then the linker will set it up as a DLL. Notice that I’m not building the ‘.a’ export file for this DLL. Visual C++ wouldn’t like it anyways, so I don’t need it.

Next, using Visual C++ (I would *assume* just about every version can do this..) I re-build the DLL to create the export library. Yes I know this is weird, but it is the quickest way I know to do this.

cl /c /LD dll.c
link /DLL dll.obj

Cool, now we’ve built dll.c as a DLL under both MinGW & Visual C++. Now for a ‘test’ program to drive our ‘staticly linked’ dynamic link library.

test.c

void main(void)
{
int j=hi();
printf(“%d\n”,j);
}

Ok, now with that out of the way, let’s compile & link!

cl test.c dll.lib

Cool, now we’ll have a test.exe!

Let’s run it!

c:\msys\1.0\src\dlltest>cl test.c dll.lib
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 15.00.21022.08 for 80×86
Copyright (C) Microsoft Corporation. All rights reserved.

test.c
Microsoft (R) Incremental Linker Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.

/out:test.exe
test.obj
dll.lib

c:\msys\1.0\src\dlltest>test
3

Wow that was exciting! Now for the people paying attention, you’ll remember that the test.exe was linked against dll.lib which was built with the Microsoft compiler, and is calling the Microsoft generated dll.dll. Yes you are correct. But always test with a known positive, before you throw in the negative I say…

c:\msys\1.0\src\dlltest>move test.dll dll.dll
Overwrite c:\msys\1.0\src\dlltest\dll.dll? (Yes/No/All): y
1 file(s) moved.

c:\msys\1.0\src\dlltest>test
3

Holy crap! It worked!!!!

That’s right, now I have built a very simple test program that’ll call a DLL function built with MinGW!

And that, is how you can get around a kooky problem where some programs build with one version of a compiler tweaked one way, and you want to use those bits in another program built another way.

Just ask any language refugee from the 1980’s how hard this was to do on the PC platform.. While VMS had a common library spec for all languages, not every platform (MS-DOS,UNIX) was as lucky. But with the rise of things like Windows with DLL’s, and of course NT thanks to the VMS crew it’s in modern systems today.

Let me tell you, linking Quick Basic to C was… not all that much fun. And Turbo C++ was right out!

Anyways I’ll leave you with this much, and at the worst case, much like making bootable CD’s, it’s a good note for me to find this stuff later when I need it.

SIMH on the DEC Alpha…

I released a partial binary build of SIMH on the DEC Alpha using Visual C++ 6.0 … I didn’t think much of it, but it’s been downloaded 400% more then I had thought…. (I didn’t think anyone would!)…

I can either conclude that:

  • There are some DEC Alpha NT users still out there…
  • Some people download things for the sake of downloading…

If you are one of the four remaining users, let me know… I have Visual C++ 6 I can try to build other stuff….

In the meantime, here is VMS on WNT…

VAX./VMS running on a Dec Alpha / NT machine

 

Some updates..

I had a request for the qemu 0.90 binaries to run NeXTSTEP… I don’t own Vaxenrule.com anymore so for now I’ll put them here:

http://dl.dropbox.com/u/1694005/qemu090%20for%20nextstep.zip

Sorry for the bitrot stuff… 😐 At least I’m still here.

Also while working on Tradewars C today, I came across this great package called OpenDoors. Even better is that it’s under the LGPL. The only “downside” is that OpenDoors requires Visual C++ 6.0 or higher to build, because of the toolbar.. Also I’m not sure if going from VC 1.0 to 9.0 didn’t flake some stuff out as well… I’m not 100% sure about it, but the trading part of the game feels.. weird.

The examples are pretty straight forward, and it took a few hours on & off for me to convert the standalone tradewars into a door program. I like the feel of it so much I may try to see about converting SIMH to run with it.. Maybe even dumbfrotz.

OpenDoors trade wars

OpenDoors trade wars

Above is a picture of what the console looks like.

Visual C++ 4.0 arrived today!

For the RISC cpu!… That being Alpha & MIPS. Although the back of the box does mention PowerPC there is no PowerPC anything here…

Visual C++ 4.0 RISC box

Visual C++ 4.0 RISC box

I always did like the old Microsoft boxes during this time period… They always looked somewhat professional, not like today’s weird boxes that look like some kind of toy should be inside.

Also speaking of RISC cpu’s check the back of the Visual C++ 2.0 for mips box:

Visual C++ 2.0 MIPS box back

Visual C++ 2.0 MIPS box back

You have to remember it was “time” the golden age of the promised RISC cpu… Intel was hitting that wall with the 486, but lo the pentium changed all of that. And the Pentium PRO cemented all the little RISC cpu’s death. It’s funny how at the same time the “itanic/itanium” is just as dead as well.. MIPS. At least MIPS has their embedded space.. Which is funny looking back at the R4000 as a workstation CPU, and now it’s available in handhelds & set tops.. Although the Acorn derived strongarm is well… Strong-arming MIPS & Power for embedded dominance.

I’m pretty sure that Visual C++ 4.0 brought a lot of Windows 95 like functionality to NT, so I’ll have to see just how much(or little) of modern stuff will build. According to this link, 4.0a was the LAST version to support the MIPS, so Unless I can find 4.0a this is as good as it’s going to get.

If anyone has either insight on where to get Visual C++ 4.0a for the MIPS, or even where to get NT 3.1 for the Alpha give me a line…. Not to mention service pack 3 for the MIPS running NT 3.1… I have a feeling the shiped kernel is at fault in the emulator…

Visual C++ 2005 project & exe’s for SIMH 3.7-3

I’ve uploaded onto the sourceforge site, my project source & the resulting exe’s

I need to see which compiler generates the faster exe, and ship with that going forward for the win32 platform. I suspect its VC2005, but the race is going to be between VC2005, gcc/mingw, Watcom 11.

Of course if anyone want’s to suggest another C compiler for win32, I could always try it out, and see how it performs.

Of course today is 9/11… It’s hard to believe that it’s been 6 years. One can only hope the madness will end.