grunwald@flute.cs.uiuc.edu (04/28/89)
I'm looking for a reference/primer/tutorial on optics in computing, esp. w.r.t. interconnection technologies. The reference I have found to date (although I've only leafed through a copy) is ``Optical Computing: A Survey for Computer Scientists'' by Dror Feitelson, MIT Press. I chanced across this & it was latter recommended by someone building a bit-serial optical computer, so I assume it's a good reference. Are there any other good primers? -- Dirk Grunwald Univ. of Illinois grunwald@flute.cs.uiuc.edu
mfinegan@uceng.UC.EDU (michael k finegan) (04/28/89)
In article <GRUNWALD.89Apr27232655@flute.cs.uiuc.edu>, grunwald@flute.cs.uiuc.edu writes: > > I'm looking for a reference/primer/tutorial on optics in computing, esp. > w.r.t. interconnection technologies. ... > Are there any other good primers? "Special Issue on Optical Computing",Proceedings of the IEEE, Vol. 72, No. 7, July 1984. The first article is a good overview, while one which might interest you is the article by Goodman, et al, titled "Optical Interconnections for VLSI Systems". "Digital Optical Computing", Optical Engineering, Vol. 25, No. 1, January 1986 is another special issue. - Mike Finegan mfinegan@uceng.uc.edu
mcdonald@uxe.cso.uiuc.edu (04/30/89)
I have been having a moderately heated (for Usenet, especially for comp.lang.c) discussion with Doug Gwyn about architectures (hardware or software) that prevent a given program from accessing the same information as both code and data. The context of the discussion is that I want(ed) the ANSI C standard to REQUIRE that one be able to access a given object as both data and code. He seems to think that this is a "Bad Idea". I think it is not only a "Good Idea", but that it is vitally important to some of my programs. I want to start a discussion here. I am NOT - read my lips - referring to what is usually called "self modifying code", but rather "incremental compilation". What my programs do is to take user input in the form of arithmetic expressions, usually moderately complicated ones, and convert them by a simple compilation process into code. This code is then executed repeatedly inside big loops of numerical integrators. Tests show that using an interpreter scheme is essentially too slow. I could probably use some sort of scheme like p-code, but even that would still be slower than compilation. Popular "compile and go" environments like Turbo Pascal also seem to use this concept. I would like to know why some designers would like to prohibit this. I can not see ANY reason why it would be desirable to prevent it. I can understand the reasons why it might take a system call at run time (like in OS/2) or a specific declaration at link time (like in VMS) and why on some architectures (80286, 80386) one would have to use two overlapped segments, and even why on some machine there might need to be a cache flush. But I cannot see any possible ADVANTAGE to the designer in preventing it - why remove from the list of possible purchasers of your hardware or OS those users who need it? Is it just basically that some designers are rooted in the old fashioned "compile now, run later" philosophy that they can't even conceive of this? That is the only RATIONAL answer I can think of. Doug McDonald
mash@mips.COM (John Mashey) (05/01/89)
In article <46500061@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: .... >I am NOT - read my lips - referring to what is usually called >"self modifying code", but rather "incremental compilation". .... >I would like to know why some designers would like to prohibit this. >I can not see ANY reason why it would be desirable to prevent it. >I can understand the reasons why it might take a system call at >run time (like in OS/2) or a specific declaration at link time >(like in VMS) and why on some architectures (80286, 80386) one >would have to use two overlapped segments, and even why on some >machine there might need to be a cache flush. But I cannot see >any possible ADVANTAGE to the designer in preventing it - why >remove from the list of possible purchasers of your hardware or >OS those users who need it? >Is it just basically that some designers are rooted in the >old fashioned "compile now, run later" philosophy that they can't >even conceive of this? That is the only RATIONAL answer I can think of. There are some advantages in prohibiting this. The old Burroughs B5xxx machines relied on the inability of a user program to generate code on the fly directly for certain protection assists. Some hardware may require overlapped segments, as you note, and certainly anybody with split I & D caches always considers this ugly. I do agree with you, though: it has to be supported somehow. (In fact, that leads to an interesting area for standardization: there are enough machines around now that require cache-flusing by a user program at some time or other, that it would be REALLY DESIRABLE to standardize the function calls used to accomplish this. Would anybody out there care to offer definitions of the cache-flushing calls they offer on their systems?) -- -john mashey DISCLAIMER: <generic disclaimer, I speak for me only, etc> UUCP: {ames,decwrl,prls,pyramid}!mips!mash OR mash@mips.com DDD: 408-991-0253 or 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
cliff@ficc.uu.net (cliff click) (05/01/89)
In article <46500061@uxe.cso.uiuc.edu>, mcdonald@uxe.cso.uiuc.edu writes: [deleted stuff about not being able to access code as data] > I am NOT - read my lips - referring to what is usually called > "self modifying code", but rather "incremental compilation". > Popular "compile and go" environments > like Turbo Pascal also seem to use this concept. > Is it just basically that some designers are rooted in the > old fashioned "compile now, run later" philosophy that they can't > even conceive of this? That is the only RATIONAL answer I can think of. > Doug McDonald I have implemented several programming environments that essentially did this - and I got a *LOT* of mileage out of it. I vote *YES* for non-compiler writers to be able to generate & execute their own code! -- Cliff Click, Software Contractor at Large Business: uunet.uu.net!ficc!cliff, cliff@ficc.uu.net, +1 713 274 5368 (w). Disclaimer: lost in the vortices of nilspace... +1 713 568 3460 (h).