El 15/01/2013, a les 1:41, sampsa at mac.com va escriure:
Has anybody tried to set this up? I think it'd be nifty if we had say Hercules with MVS connected to HECnet..
The hardware part in the IBM side has not been emulated afaik... You need a 3745 if I'm not wrong, and Hercules don't provide that.
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
If someone is interested, I have published the source code and the basic circuitry I have been using. I have also built a virtual console for the virtual pdp-11. Or if you like it more, a simulation of the simulated console for the simulated PDP-11.
http://ancientbits.blogspot.com.es/2013/01/blinkenlights-not-so-difficult-a…
Jordi Guillaumes i Pons
jg at jordi.guillaumes.name
HECnet: BITXOV::JGUILLAUMES
PS: This mail _could_ end being duplicated... I apologize for it
On 15 Jan 2013, at 19:55, Clem Cole wrote:
So, if you really want to do this type of analysis, I think for the effort you suggesting, it be worth the extra time to dig up a copy of specint and run that not whetstone. What is cool is that all the manufacturers published their spec numbers so you can see what you should expect and what you get so you'll have real base line and be able to make some more direct inferences.
*FORGET* I ever asked... ;)
--
Mark Benson
http://DECtec.info
Twitter: @DECtecInfo
HECnet: STAR69::MARK
Online Resource & Mailing List for DEC Enthusiasts.
I should point out, I speak for my self in all of this not for my employer or previous ones.
On Tue, Jan 15, 2013 at 12:17 PM, Tim Sneddon <tim at sneddon.id.au> wrote:
It did do IA-32, IA-64, Alpha, MIPS.
And INTEL*64 to an extent (although it was not released). As I understand it, the project was show it could be done and it was fodder/part of the GEM vs Intel C war that GEM lost. But as I understand it from my compiler friends, it was fairy easy to take the x32 tables and make them 64 bits and add new instructions. The advantage was the IL was easier to do some of the cool things INTEL*64 needs but alas it was in BLISS and Intel was not going to base it's compiler's on BLISS (which I can understand from a business standpoint].
As Grove once told me, GEM was designed to be a compiler to last 25 years. They knew it would have to support a number of features we now re having a heck of time dealing with in today's code generators and ILs. No other suite so far has done as wide job and able to handle the diversity of languages and architectures.
GCC has been made to work, and was the first FOSS compiler to come close. But the difference between GCC's code generator for INTEL*64 compared to icc is not even close for real applications programs.
It will be interesting to see if LLVM is able to do as well as GEM did. You have a lot of the thought leaders in compiler land betting on it. Apple's moved to it. Intel will do something with it for the Exascale machines because DOE wants it, as will IBM or any other firm that wants to "prime" a Supercomputer in the future I would bet (but do not know).
On 2013-01-15 22:27, Clem Cole wrote:
On Tue, Jan 15, 2013 at 3:55 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
he DEC PDP-11 C runs on the PDP-11, it's not a cross compiler.
Interesting, I learned something here. As I said - by that time, I
long lost interest in the 11.
I'll have to ask around up here in compiler land if anyone remembers
anything about it and who led its development.
I have that information *somewhere*. If noone else can recall, I'll try and dig it up.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On Tue, Jan 15, 2013 at 4:01 PM, Johnny Billquist <bqt at softjar.se> wrote:
But I'm not talking about cross compilers or subsets. That is a totally different topic. I guess you are arguing that PL/1 is still PL/1, and is not heavy because it's old and not so full of features.
That is probably true in itself, but I still suspect that the requirements of a PL/1 compiler written in PL/1 are much higher than a PL/1 compiler written in assembler.
Hmm I don't think so. In it's day PL/1 was full of features. But that said, I really don't remember too many people tried to write PL/1 compilers in assembler - maybe IBM, but I never looked at the sources to their PL/1 (or at PL/C as I mentioned before so I don't know for sure).
That said, by the time PL/1 came on the scene (late 1960s/early 1970s), it was pretty much de rigro that that a compiler was written in it self to demonstrate the power of the language. And the boot strap compiler was one a one shot thing and tossed aside as soon as a working compiler staggered to its feet (think Ken Thompson's Turing Award lecture on security). For instance BLISS was said to have been boot strapped as a set of TECO macro's on the 10 - Eklund says he does not remember, but he did tell me once that it might have been so when I asked him [While I was there, I was not part of that thread - where as Dave was one of Wulf's grad students at CMU when Bill designed and implemented BLISS -- Eklund is still hacking on the Intel FTN Compiler a few days a week BTW].
The Multics, Prime et al PL/1 were written in PL/1 (by Frieberghouse) - which is why Culter went there to get the front end when he created his company. Again, I do not know how it was boot strapped. It's possible PL/1 for Multics was bootstrapped from GECOS and in something like BCPL - anyone know? Also, there were a number of firms at the time in the Boston area doing compilers.
Also this time was towards the end of the assembler vs HLL fight. While Cutler would doggly stay with Macro for implementing VMS, much of the rest of DEC had already been convinced (inc GB). I remember an experiment done at CMU around that time where they took N of the best assembly language programmers for the PDP-11 and gave them programming tasks. BLISS-11 at least did as well in all cases and in most non-trivial tasks, beat the macro coders (I wonder if I still have that paper - if I do I'll try to find it on line or post it),
In the mid 1980's I got into an argument with Dave about VMS (it was an interesting night and I'll relay the whole exchange) but Dave defended his Macro32 choice and his crazy file system spec stuff). Dave Cane (VAX 750 architect and one of the 780 guys) always says that Cutler wanted the words greatest assembler machine. But I contend that Dave could have used BLISS (or any of a number of "systems programming" languages if he had wanted too. He did not buy any speed in authorship or operation.
Frankly, having lived that era, you will never convince me otherwise. BLISS was cool, but for some marketing mistakes it would have beaten C no doubt - although the syntax in hindsight was a mistake (and I heard Wulf admits that - we all had a long chat about it in the late 1980s/early 1990s at Stellar and Bill was as "Jr Programmer" helping with the code generator for the Stellar box).
Clem
On Tue, Jan 15, 2013 at 3:55 PM, Johnny Billquist <bqt at softjar.se> wrote:
he DEC PDP-11 C runs on the PDP-11, it's not a cross compiler.
Interesting, I learned something here. As I said - by that time, I long lost interest in the 11.
I'll have to ask around up here in compiler land if anyone remembers anything about it and who led its development.
On 2013-01-15 18:33, Clem Cole wrote:
On Tue, Jan 15, 2013 at 12:05 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
Right. I'm sure that with enough work, you can always do it, but I'm
curious on how much work. I have a feeling that compilers written in
high level languages rapidly expand their requirements...
Its not that actually - IMHO. You can always use overlays and thunks
to write code that works on a small address machines, like the PDP-11.
I think the problem is that people that used / wanted the language did
not need all of the features and frankly time moved on. The languages
themselves were just too heavy not the compiler per say - the compilers
became heavy to support the language features people wanted.
If PL/M or PL/360 had not lost to C (BCPL et al), it might have been
different in the case of PL/1. If you note sub-set C compilers for the
8 and 16 bit machines exist or often exist as cross compilers from
larger systems.
The issue is that 16-bits of data space is >>very<< limiting for a
programmer, the code space can be swapped in and out with automatic or
managed overlays - but data space is much harder to do.
But I'm not talking about cross compilers or subsets. That is a totally different topic. I guess you are arguing that PL/1 is still PL/1, and is not heavy because it's old and not so full of features.
That is probably true in itself, but I still suspect that the requirements of a PL/1 compiler written in PL/1 are much higher than a PL/1 compiler written in assembler.
The DEC PDP-11 C compiler is not a subset, but is a pretty complete ANSI C. And it is not a cross compiler. But the requirements of the compiler is high, and the code it produces aren't that great.
The FORTRAN 77 compiler, as a comparison, produces much better code, and do lots of more optimizations. Heck, even the DECUS C produces better code (that is, when it actually manage to compile anything at all, it's a very retro K&R C implementation).
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
On 2013-01-15 18:19, Clem Cole wrote:
On Tue, Jan 15, 2013 at 12:05 PM, Johnny Billquist <bqt at softjar.se
<mailto:bqt at softjar.se>> wrote:
I don't think it was, but It's hard to say, as it's just one big
binary blob to me. However, would the GEM even fit on a PDP-11?
It would not easily self host, but few of the PDP-11 compilers were
asked to self host. They started cross compiling from the 10's then
from the Vaxen. By the time PDP-11 went EOL, the cross compilers were
running on Alpha (and maybe PMAX - again too man beers ago).
The the DEC PDP-11 C runs on the PDP-11, it's not a cross compiler.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt at softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
Erik Olofsen <e.olofsen at xs4all.nl> writes:
Perhaps we could compare dumps of various monitor.exes.
The command procedure actually opens up three more classes: VMS1, VMS2,
and VMS3; their output follows for interested readers; but unfortunately
on my system no items seem to be reserved :)
VAX/VMS Monitor Utility
VMS DEVELOPMENT 1 on node
RULLFS 15-JAN-2013 21:13:53
CUR AVE MIN
MAX
FCP Call Rate 0.00 0.00 0.00
0.00
Volume Lock Req. Rate 0.00 0.00 0.00
0.00
Volume Lock Wait Rate 0.00 0.00 0.00
0.00
Other Sync Lock Req. Rate 0.00 0.00 0.00
0.00
Other Sync Lock Wait Rate 0.00 0.00 0.00
0.00
Access Lock Req. Rate 0.00 0.00 0.00
0.00
Cache Wait Rate 0.00 0.00 0.00
0.00
FYI, FCP is now a recognised class in MONITOR.
The MONITOR command initiates monitoring of statistics for the
classes of information you specify.
Format
MONITOR [/command qualifier[,...]] classname[,...] [/classname
qualifier[,...]]
Additional information available:
Parameter Command_Qualifier_Descriptions
/BEGINNING /BY_NODE /COMMENT /DISPLAY /ENDING /FLUSH_INTERVAL
/INPUT /INTERVAL /NODE /OUTPUT /RECORD /SUMMARY
/VIEWING_TIME
ALL_CLASSES CLUSTER DECNET DISK DLOCK FCP
FILE_SYSTEM_CACHE IO LOCK MODES MSCP_SERVER
PAGE PROCESSES RLOCK RMS SCS STATES SYSTEM
TIMER TRANSACTION VBS VECTOR
--
VAXman- A Bored Certified VMS Kernel Mode Hacker VAXman(at)TMESIS(dot)ORG
Well I speak to machines with the voice of humanity.
