ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe) (05/25/90)
In article <26900003@teapot>, milgr@teapot.prime.com writes: > I like Quintus, however it is out of my department's price range for > two reasons: > 1. Quintus does not want to port to Primos. I suppose that if > Prime paid enough, Quintus might, but our budget is real > limited. What's one of the big no-nos for writing portable C code? Assuming that 'foo *' and 'long' (or possibly 'int') are the same size. If you were twiddling tag bits on pointers in C, what assumption would be very natural, indeed, very hard to avoid? What machines does that break on? [Hint: the name starts like PR...] Given that the Quintus Prolog emulator was designed for machines with "enough" general registers, and that a PR1ME 50-series machine running in 32V mode has, strictly speaking, _no_ *general* registers (you think the 386 is bad? You've not seen 32V mode), is it a surprise that Quintus don't want to port to PR1MEs? Then too, there are those 64 kword (where word=16 bits) segments. 32I mode may be able to ignore them, but in 32V mode the X and Y index registers wrap around at 16 bits. A PR1ME pointer is 1 "validity" bit (is the pointer usable at all) 1 "length" bit (is this a 32-bit or a 48-bit pointer?) 2 "ring" bits (protection ring 0=kernel,1=system,3=user) 12 "segment" bits (the 4k segments are divided, roughly, into O/S 00xxxx, shared libraries 01xxxx, user 10xxxx, system per-user data (e.g. command interpreter) 11xxxx; so a user process has up to 1k segments; this was under PR1MOS, what PR1MIX does I have no idea) 16 "word" bits (16-bit word within segment) 4 "bit" bits (in a long pointer, actually only 1 bit is used) 12 "spare" bits (in a long pointer) X- and Y-register indexing affects only the "word" bits of an address. If you want an array bigger than 64kwords, you have to use the L register and do the addition yourself. The PCL (procedure call) instruction poses serious difficulties of its own, which I'll skip. Suffice it to say that I'm sure it suits Fortran 77 very well. I have written assembly code for a P400. (The first model from PR1ME to include the 32V instruction set.) If you've read Stephen Jay Gould's "Wonderful Life", you'll understand when I compare it to Opibinia. How can something that strange live? I regard the people who put Salford Prolog together as heros of the modern world, even if they did make a number of pointless changes to Prolog. Anyone who has what it takes to make a usable Prolog system on so unrelentingly hostile an architecture has my whole-hearted admiration. I think they deserve that market niche to themselves! Let me offer you a fair comparison: I was one of the people who made Quintus Prolog run on Xerox Lisp machines. That hasn't got C at all. It is my considered opinion that it would be more work for Quintus to port Quintus Prolog to PR1ME machines running the 32V instruction set than it was to port Quintus Prolog to Xerox Dandelions. I no longer work for Quintus, and am not privy to their future porting plans, but I would be _very_ surprised if they announced a PR1ME port any time this century. -- "A 7th class of programs, correct in every way, is believed to exist by a few computer scientists. However, no example could be found to include here."
jeff@aiai.ed.ac.uk (Jeff Dalton) (05/26/90)
In article <26900003@teapot> milgr@teapot.prime.com writes: >Small (trivial) exmaple of why predicate-based modules are better for >my needs: Ok, a minor point: I suspect that predicate-bases systems may always be at least somewhat better for some things. So the real question is whether the difference will be great enough in a large enough number of cases. I don't know the answer. >:- module(rev20_ctrlr_info). >:- import([addr_to_ctrlr, dsk, amlc, ...]). >:- use_module([cpu_info]). % defines cpu_type, alpha, degraded_mode. Here I wonder why you have to list dsk, amlc, etc. explicitly. Why can't you say use_module for some module that cointains them all? If you don't want to tye in the export list for that module, you might be able to have a program generate it. Another approach might be to allow some modules access to internal symbols in certain other modules (just as derived classes in C++ can have access to some of the internals of their base class). I know this is a fairly vague description, but something along those lines might be possible. >Secondly, if I want to modify one module, it appears that I need to >reload all of the modules in order to compile one module. (Prologix >has an interpretter with a compiler built in. One must load in a file >to compile it). This sounds like an artifact of the particular implementation you are using. That sort of thing can happen with predicate-based systems too. For example, if you import from some module, the compiler may have to look at that module to see if anything it exports is a meta-predicate.