cik@l.cc.purdue.edu (Herman Rubin) (07/10/90)
In article <1990Jul10.072443.4844@cs.UAlberta.CA>, cdshaw@cs.UAlberta.CA (Chris Shaw) writes: > In article <2328@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >In article <3627@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes: [ As much flaming as possible omitted. ] > Plus assembler is a nightmare unless one of three things is true: > 1: The project is performed by 1 person. > 2: The project is small (less than 5000 lines) I do not believe that even a 100 line program should be produced by one person. Anyone can miss too much. > 3: All modules adhere strictly to a call-return convention. I have no difficulty with spaghetti code when I need it, and I often move code blocks off for efficiency. In fact, the call-return convention is most annoying from the standpoint of efficiency, and I am quite aware of this annoying fact. Most of the present assemblers are horrors, but there are a few, like CAL on the CRAYs, or COMPASS on the CDC 6x00 and related machines, which were a step in the right direction. > In other words, you can do it, but it's extremely hard work if you're building > something non-trivial. Anywhere up to 1000 lines of code is trivial. > Besides you're still going to suff a drop in productivity vs HLL's. ..................... > >Examples of simple instructions in hardware, much more expensive in software, > >and for which I know of "reasonable" applications. Examples omitted. If you believe that the chips mentioned do this, how do I get a description of these to verify this? It is possible to see what hardware can do by reading the description. > And if you're going to rant on (as you always do) about misfeatures in > well-known programming languages, why don't you get off your duff and prove > all us fools wrong? Show conclusively that modern HLLs stink by designing > one that doesn't stink. Do the same for assemblers, too. > So quit your bitching already. If you have read what I have written, you would know that I do not believe a good HLL is possible. So, even if I had the resources (and they are very scarce for things like this in an academic environment), why should I try? As for assemblers, adding weak typing and good macro capabilities (the macro should have an arbitrary syntax) to something like CAL would do a good job. Not everyone has flamed. There are those who have been sympathetic. If someone came to me with a statistical problem involving calculations which the standard packages cannot do (a common situation), if he had the programming resources, I would help him do it instead of just telling him to stop complaining. With the present situation in which funding is almost entirely from the federal govennment, getting the necessary $30,000 or so to produce the versatile macro translator is next to impossible. It is almost impossible to get graduate students to assist on faculty statistics research projects. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
peter@ficc.ferranti.com (Peter da Silva) (07/11/90)
In article <2336@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > getting the necessary $30,000 or so > to produce the versatile macro translator is next to impossible. What do you envisage this versatile macro translator as supporting? What should it do that conventional macro assemblers can't? -- Peter da Silva. `-_-' +1 713 274 5180. <peter@ficc.ferranti.com>
jkenton@pinocchio.encore.com (Jeff Kenton) (07/11/90)
From article <2336@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): > . . . > to stop complaining. With the present situation in which funding is almost > entirely from the federal govennment, getting the necessary $30,000 or so > to produce the versatile macro translator is next to impossible. It is > almost impossible to get graduate students to assist on faculty statistics > research projects. Sometimes you give the impression of wanting a processor designed to your specifications exactly. However, if all you need is a macro package, life shouldn't be that tough. If none of the standard tools is adequate, you ought to be able to have one written to your specs in about a week no matter what your requirements are, either as a separate preprocessor or as part of an existing assembler. A competent grad student won't cost anywhere near $30,000. Neither would a consultant charging "the usual exorbitant fee". If you really want, it's out there somewhere, just waiting for you to find it. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - jeff kenton --- temporarily at jkenton@pinocchio.encore.com --- always at (617) 894-4508 --- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
new@udel.EDU (Darren New) (07/11/90)
In article <12229@encore.Encore.COM> jkenton@pinocchio.encore.com (Jeff Kenton) writes: >From article <2336@l.cc.purdue.edu>, by cik@l.cc.purdue.edu (Herman Rubin): >If you really want, it's >out there somewhere, just waiting for you to find it. He's already found it. I sent a macro expander I did in my spare time to him, based on ideas from the book below but broght up to date with newer language concepts (like subroutines instead of assigned goto). I've never heard from him again; he doesn't answer my personal mail. I can make the code available to anybody who wants it. (My apologies if he never got the mail and it never bounced, but I doubt that this is the case.) @book{Wait73, author = "William M. Waite", title = "Implementing Software for Non-Numeric Applications", publisher = "Prentice-Hall, Inc.", year = 1973, comment = "isbn = 0-13-45898-5, lib of cong num 72-1768" }
cik@l.cc.purdue.edu (Herman Rubin) (07/11/90)
In article <9896@celit.fps.com>, dave@fps.com (Dave Smith) writes: > In article <63692@sgi.sgi.com> karsh@trifolium.sgi.com (Bruce Karsh) writes: > >In article <1990Jul10.072443.4844@cs.UAlberta.CA> cdshaw@cs.UAlberta.CA (Chris Shaw) writes: > >>The basic problem with assembly coding by hand vs assembly coding by compiler > >>is that IT DOESN'T SCALE. There are extremely limited application areas where > >>coding by hand is much faster, and you, Herman, live in one. ..................... > For 90% of programmers assembly is more trouble than it's worth. (Though I > do remember that on the Apple II I prefered assembly to Applesoft because > it was easier to make the machine do what I wanted :-) ) Computer > manufacturers market to the 90% and will build machines suited to the 90%. I would certainly agree that for 90% of the programming assembly is more trouble than it is worth, maybe a lot more. I disagree for 90% of the programmers. And even these programmers use library tools, which should not be in that fraction. Those programmers, and users of their programs, benefit from efficient software produced by the few others. I would not want my automobile designed by those who know as little automotive engineering as I know. I would hope that there are "unorthodox" people on the design team, who can think of how to improve things by doing the "unheard of." How many of the 90% do not even know of the existence of these possibilities? Are we making it difficult for them to understand them by teaching the present HLLs? I have advocated that the HLLs remove their limitations in such a way as to enable easier inclusion of machine features into the program. Also, that the assembler syntax be changed to make the use of these features much easier, so that Dave Smith's observations about the Apple II can be readily used. In addition, that computer manufacturers include the hardware; computing chips are a small part of the cost of computers, and even a VCISC coprocessor would be relatively cheap. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
dave@fps.com (Dave Smith) (07/12/90)
In article <2338@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >In article <9896@celit.fps.com>, dave@fps.com (Dave Smith) writes: >> For 90% of programmers assembly is more trouble than it's worth. (Though I >> do remember that on the Apple II I prefered assembly to Applesoft because >> it was easier to make the machine do what I wanted :-) ) Computer >> manufacturers market to the 90% and will build machines suited to the 90%. > >I would certainly agree that for 90% of the programming assembly is more >trouble than it is worth, maybe a lot more. I disagree for 90% of the >programmers. And even these programmers use library tools, which should >not be in that fraction. Those programmers, and users of their programs, >benefit from efficient software produced by the few others. I would not >want my automobile designed by those who know as little automotive engineering >as I know. I would hope that there are "unorthodox" people on the design team, >who can think of how to improve things by doing the "unheard of." Don't get me wrong. Assembler is fine for some tasks, however, when it comes down to a tradeoff between making it easier for the compiler to do something or easier for the programmer to do something (in assembly) the compiler wins because the compiler is what's going to be used most of the time. In order to be successful in the processor game you have to sell lots of CPU's and this means running fast on compiled code. The number of users who are going to look at your assembler and go "Ick, that's really grody" and have that be a major point with them are few. The number who want to see how fast your code goes out of the compiler with no hand-tweaking are much larger. I've been working at FPS (then Celerity) for almost three years doing systems programming day in and day out. I still haven't gotten around to really learning the assembly code for the Accel processor. About twice a year I have to go find someone who does know the assembly code well to help me figure out why something is happening. The rest of the year I do my work in C and it all works fine. Now, we're moving a lot of our stuff over to the SPARC and Accel knowledge will not be very helpful. The time I've spent honing my knowledge of C and Unix internals instead, however, is still very valuable. Would learning Accel have been a waste of my time? I think so, since the effort versus value, for me, would have been quite high. >How many of the 90% do not even know of the existence of these possibilities? >Are we making it difficult for them to understand them by teaching the present >HLLs? I've been of the opinion for a long time that assembler should be taught first so that a student does have an idea of what the machine does when it comes time to learn what a pointer is, or dynamic memory, or data alignment. Programming in an unstructured environment where you have to manage the stack and all your memory by hand also gives you a much greater appreciation of all the things an HLL does for you when you move on to one. Besides tweaking for speed and messing with things the language is trying to do for you (like stack management) I don't know of too many things that assembler is really good for. Any other applications? >I have advocated that the HLLs remove their limitations in such a way as >to enable easier inclusion of machine features into the program. Also, that >the assembler syntax be changed to make the use of these features much easier, >so that Dave Smith's observations about the Apple II can be readily used. In >addition, that computer manufacturers include the hardware; computing chips >are a small part of the cost of computers, and even a VCISC coprocessor would >be relatively cheap. Place an order for 5 machines and tell us you want a VCISC coprocessor and you'll fund the development and we'll be happy (I think, I don't work in management (pun not intended)) to build you one. Until the marketplace tells us that is what it wants, though, we're not going to do it. Marrying your code too tightly to the hardware will probably come back to bite you anyhow. Are you using today's hardware to run your code on, Herman, or is it running on an older machine because that's what it's all been hand-tuned to run on? If it will run faster (without tweaking) on a newer machine then you've already lost. High level languages are what allows the kind of competition that's going on today between computer manufacturers. If customers were unable to jump ship when someone else's box ran faster there would be no incentive to provide a better box. Assembler's good for when you want to get down and dirty, but the percentage of your programming that should be done in assembler is so small that there's no real point in making assembly easier at the expense of speed or ease in the rest of the code. -- David L. Smith FPS Computing, San Diego | ucsd!celerity!dave or dave@fps.com All opinions disowned by me and FPS unless financially lucrative (to me, not the litigator)
nevin@igloo.scum.com (Nevin Liber) (07/12/90)
In article <2336@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >I do not believe that even a 100 line program should be produced by one >person. Anyone can miss too much. Do you really believe that programming by committee is better? I feel that code should be REVIEWED and INSPECTED by someone other than the original author, but I have enough faith in my fellow colleagues to be able to produce 100 line programs reasonably well. Also, do you practice what you preach? Is all of your code written by a group of people instead of just yourself? >I have no difficulty with spaghetti code when I need it, Are you the one who maintains the code that you write? When your code is moved to another machine/architecture/compiler, do you do the port, and if so, how quickly? There is already too much code out there which can't be changed because everyone is afraid that undocumented side effects were taken advantage of, and no one is quite sure how much other code will break if it is changed. >If you have read what I have written, you would know that I do not believe >a good HLL is possible. Then stop complaining that we can't do the impossible! >So, even if I had the resources (and they are very >scarce for things like this in an academic environment), why should I try? Exactly what resources do you need? I wrote my first assembler during my freshman year of college, and all I had was a 2400 baud ADM-5 terminal connected to an overloaded (70+ users) VAX 11/780. I still managed to get it working in just a few short weeks, and I had four classes and a job leaving me with precious little time to devote to the project. Plus it was the FIRST assignment in the course, NOT the LAST one! I can't believe that terminals and computers are scarce at Purdue. >With the present situation in which funding is almost >entirely from the federal govennment, getting the necessary $30,000 or so >to produce the versatile macro translator is next to impossible. How could you even justify spending $30K on this project? What makes this project so much more complex than a typical assembler or even a compiler? Maybe the government won't fund you because it can't see the value of the results of this project. >It is >almost impossible to get graduate students to assist on faculty statistics >research projects. Er, I thought that one of the things a grad student had to do was to help faculty on their research projects. Maybe the project just isn't rewarding enough. -- NEVIN ":-)" LIBER nevin@igloo.scum.com or ..!gargoyle!igloo!nevin (708) 831-FLYS Advertisement: Hire me!
amos@taux01.nsc.com (Amos Shapir) (07/12/90)
In article <2336@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > >Most of the present assemblers are horrors, but there are a few, like CAL >on the CRAYs, or COMPASS on the CDC 6x00 and related machines, which were >a step in the right direction. I don't know about CAL, but if it's as elaborate as COMPASS it's a step in the wrong direction, or at least a step too far. While some macro capability is welcome, things like COMPASS are addictive; programmers end up using them to write programs that looks nice in the source, but the generated code ends up being worse than what any HLL would do. > >As for assemblers, adding weak typing and good macro capabilities (the >macro should have an arbitrary syntax) to something like CAL would do >a good job. This is exactly what BCPL is; and BCPL begat B, and B begat C... What we need is an intermediate level language, like C used to be in the Good Old Days. -- Amos Shapir amos@taux01.nsc.com, amos@nsc.nsc.com National Semiconductor (Israel) P.O.B. 3007, Herzlia 46104, Israel Tel. +972 52 522408 TWX: 33691, fax: +972-52-558322 GEO: 34 48 E / 32 10 N
chip@tct.uucp (Chip Salzenberg) (07/12/90)
According to cik@l.cc.purdue.edu (Herman Rubin): >If you have read what I have written, you would know that I do not believe >a good HLL is possible. So, even if I had the resources (and they are very >scarce for things like this in an academic environment), why should I try? ... and comp.arch reverberates to the "SLAM" of a mind closing. -- Chip Salzenberg at ComDev/TCT <chip@tct.uucp>, <uunet!ateng!tct!chip>
cik@l.cc.purdue.edu (Herman Rubin) (07/13/90)
In article <2618@igloo.scum.com>, nevin@igloo.scum.com (Nevin Liber) writes: > In article <2336@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: > > >I do not believe that even a 100 line program should be produced by one > >person. Anyone can miss too much. > > Do you really believe that programming by committee is better? I feel > that code should be REVIEWED and INSPECTED by someone other than the > original author, but I have enough faith in my fellow colleagues to be > able to produce 100 line programs reasonably well. Also, do you > practice what you preach? Is all of your code written by a group of > people instead of just yourself? I mean that the programming should be done by two or three people working together. Many years ago, I produced a random number package for the 6500 with the aid of an undergraduate CS major. This was written entirely in assumbler, and was Fortran callable. The register quirks would have given major problems in a HLL. It would have taken more than twice as long if I did it by myself. BTW, it was not upgraded for the 6600, because it used a particular calling sequence. The graphics package the computing center used was also not upgraded for the same reason. Most of my code is written by myself. That is why so little gets done. > >I have no difficulty with spaghetti code when I need it, > > Are you the one who maintains the code that you write? When your code > is moved to another machine/architecture/compiler, do you do the port, > and if so, how quickly? There is already too much code out there which > can't be changed because everyone is afraid that undocumented side > effects were taken advantage of, and no one is quite sure how much > other code will break if it is changed. Spaghetti code can have a quite understandable simple structure. Algorithms requiring spaghetti code even in HLLs available on request. > >If you have read what I have written, you would know that I do not believe > >a good HLL is possible. > > Then stop complaining that we can't do the impossible! I have not complained about that. I have complained about making it difficult to insert machine instructions in HLL code. For example, the asm on C, besides having too many extra characters to type, does not allow (on the compilers I have had to use) symbolic register designations. I have complained about the horribly designed assembler format, and the lack of macro facilities to simplify the inclusion of constructs. > >So, even if I had the resources (and they are very > >scarce for things like this in an academic environment), why should I try? .................. > >With the present situation in which funding is almost > >entirely from the federal govennment, getting the necessary $30,000 or so > >to produce the versatile macro translator is next to impossible. > > How could you even justify spending $30K on this project? What makes > this project so much more complex than a typical assembler or even a > compiler? Maybe the government won't fund you because it can't see the > value of the results of this project. I have not asked the government for funding. I could probably get it. I do not really wish to supervise a project which does not involve research and is not in my field. > >It is > >almost impossible to get graduate students to assist on faculty statistics > >research projects. > > Er, I thought that one of the things a grad student had to do was to > help faculty on their research projects. Maybe the project just isn't > rewarding enough. This is definitely not the case in mathematics and statistics. One reason is that a graduate student costs as much as a full professor (I kid you not), and the current estimate is that only half the faculty who should be funded are. In fields where there is a tradition of students assisting on faculty projects on a regular basis, there is funding. This is also the case in fields where equipment, rather than salaries, is the major cost. Government red tape is worse than you think. On a project for the government, a colleqgue and I wanted to hire a programmer. We could not do this, but we could program ourselves at our consulting rates, which were much more than a programmer would be paid. -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
gilstrap@swbatl.sbc.com (Brian Gilstrap - UCI - 5-3929) (07/13/90)
In article <2347@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes: >Spaghetti code can have a quite understandable simple structure. Algorithms >requiring spaghetti code even in HLLs available on request. I'll bite. Consider this a request. Brian R. Gilstrap gilstrap@swbatl.sbc.com gilstrap@swbatl.swbt.com gilstrap@swbatl.uucp ...!{texbell,uunet}!swbatl!gilstrap -------------------------------------------------------------------------------- "You spend your whole life just piling it up there. You got stacks and stacks and stacks. Then Gabriel comes and taps you on the shoulder, but you don't see no hearses with luggage racks." --- Don Henley -------------------------------------------------------------------------------- Copyright (c) 1990 by Brian R. Gilstrap. You may redistribute (my portions of) this material for free if and only if your recipients may also do so.
ted@nmsu.edu (Ted Dunning) (07/14/90)
sorry for the deprecative air about this posting, but herman rubin
really does get tiresome.
In article <2347@l.cc.purdue.edu> cik@l.cc.purdue.edu (Herman Rubin) writes:
Many years ago, I produced a random number package for the 6500
with the aid of an undergraduate CS major.
of course, an undergraduate cs major could do it by themselves with a
copy of knuth in hand.
This was written entirely in assumbler, and was Fortran callable.
The register quirks would have given major problems in a HLL.
??? this is really hilarious.
of the major sorts of random number generators, the only possible
problem would be with the shift register generators in a language that
doesn't allow exclusive or and shifting. linear congruential,
additive sequences, even middle square (just for illustrative
purposes) are all trivial (and portable) in hll's. berkeley's random
number generator is an example of one which produces good results
(good to the last bit, as they say), is very fast, is very simple, and
is very portable.
It would have taken more than twice as long if I did it by myself.
it probably took longer with your help than it would have without your
help.
BTW, it was not upgraded for the 6600, because it used a particular
calling sequence.
?? isn't this what people are talking about when they bemoan the use
of assembly. keep in mind the fact that the 6500 and the 6600 used
the same instruction set, he is only talking about a change in calling
sequence.
Most of my code is written by myself. That is why so little gets
done.
he said it, i didn't.
Spaghetti code can have a quite understandable simple structure.
Algorithms requiring spaghetti code even in HLLs available on
request.
hmm.... last time i wrote to mister rubin asking for such an example,
he didn't deign to acknowledge the request.
why don't you _post_ such an algorithm.
I have complained about making it difficult to insert machine
instructions in HLL code. For example, the asm on C, besides
having too many extra characters to type,
horrors!! isn't your editor there to help you? emacs and even vi
could be made to add the asm(" ... "); for you nearly automagically.
couldn't you write a trivial sed script or other preprocessor that
would add them in between special punctionation? say starting at #|
and ending at |#?
does not allow (on the compilers I have had to use) symbolic
register designations.
this could be fixed at the same time.
I have complained about the horribly designed assembler format, and
the lack of macro facilities to simplify the inclusion of
constructs.
so why don't you just plug that into your preprocessor, too? or use a
real macro assembler? or write your dreaded compass revival
assembler?
This is definitely not the case in mathematics and statistics. One
reason is that a graduate student costs as much as a full professor
(I kid you not),
maybe where you work. not at this university.
and the current estimate is that only half the
faculty who should be funded are.
whose estimate? yours?
In fields where there is a
tradition of students assisting on faculty projects on a regular
basis, there is funding.
care to elaborate this and maybe support it a bit? which fields? are
you implying that having students assist faculty is the cause of
funding?
Herman Rubin, Dept. of Statistics, Purdue Univ.
^^^^^^
well, they had a good reputation.
--
Offer void except where prohibited by law.cik@l.cc.purdue.edu (Herman Rubin) (07/15/90)
In article <37569@ucbvax.BERKELEY.EDU>, tve@sprite.berkeley.edu (Thorsten von Eicken) writes: > In article <3060@osc.COM> jgk@osc.COM (Joe Keane) writes: > >One real problem with using C for threaded interpreters is that there is no > >way to make an arbitrary jump instruction. If you could `goto' some address > >expression there would be no problem. > Yep, typically the C program ends up being a hunge switch statement: > loop: switch(next_thread) { > case 0: .... goto loop; > case 1: .... goto loop; > } > and one hopes that a) a jump table is produced (and not a binary search > tree) and b) the compiler doesn't dump core with some silly error when > the number of cases reaches into the thousands... > > Or can anyone suggest a better method? For which problem? The assumption that there is a best way to handle all switches is erroneous in the first place. There are natural situations in which the switch variable is an integer, with the probabilities of successive integers decreasing sufficiently rapidly. In that case, if there is a bound after which some "default" procedure is followed, the following may beat it. switch(i){ if(i > 1) goto i2; ................. i2: if(i > 2) goto i3: ................. } I am not assuming that one necessarily returns to the loop. How for hardware dependence considerations. Many, if not most machines, have a 3-way compare. In that case, the compare operations can be halved, at no cost. switch(i){ compare i with 2; if (>=) goto i2; ................. i2: if (>) goto i3; .............. } -- Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907 Phone: (317)494-6054 hrubin@l.cc.purdue.edu (Internet, bitnet) {purdue,pur-ee}!l.cc!cik(UUCP)
jkrueger@dgis.dtic.dla.mil (Jon) (07/16/90)
cik@l.cc.purdue.edu (Herman Rubin) whines: >getting the necessary $30,000 or so >to produce the versatile macro translator is next to impossible. Guess how much your postings have cost the net so far. So why not do it for free, you've been on a free ride up 'til now. Or all you know how to do is complain? -- Jon -- Jonathan Krueger jkrueger@dtic.dla.mil uunet!dgis!jkrueger Drop in next time you're in the tri-planet area!
chip@tct.uucp (Chip Salzenberg) (07/16/90)
According to cik@l.cc.purdue.edu (Herman Rubin): >Many years ago, I produced a random number package for the 6500 >with the aid of an undergraduate CS major. This was written >entirely in assembler, and was Fortran callable. We must admit that Herman practices what he preaches: He uses assembler to do his real work. However, Herman is subsequently hoist upon his own petard: >BTW, it was not upgraded for the 6600, because it used a particular >calling sequence. The graphics package the computing center used >was also not upgraded for the same reason. Ah yes, that old bugaboo: Portability. Still think it's unimportant, Herman? >Most of my code is written by myself. That is why so little gets done. No comment.
eliot@cs.qmw.ac.uk (Paul Davison (postmaster)) (07/17/90)
I use threaded code in my dynamic translation Smalltalk virtual machine,
but its written in C. I use a single asm statement to do the 'jump to next
threaded opcode' & I use simple sed scripts on assembler code to turn C
procedures into threaded opcodes.
I've found this combination provides portability & speed. It took half a day
to port the machine independent parts of the vm (i.e. not the graphics)
from SUN 3 (mc68k) to SUN 4 (sparc).
In straight C we could define a threaded code interpreter thus:
void (**tcip)(); /* threaded code instruction pointer */
void inner_interpreter()
{
do
(**tcip++)();
while (1);
}
where an opcode could be written
void do_something()
{
....
return;
}
The resulting system would probably spend most of its time doing return/call
pairs.
With a little extra effort (& help from a good C compiler) we can eliminate
the call/return pairs & build a conventional threaded code interpreter that
jumps from routine to routine but is still written in C (well 99.9% anyway).
Here's how it works:
I use GCC so I can declare some oft used global variables in registers:
On mc68k:
register OOP *stackPointer asm("a3");
register TCODE *tcip asm("a5");
On sparc:
register OOP *stackPointer asm("%g5");
register TCODE *tcip asm("%g7");
Threaded code is a sequence of 32 bit words organized as
<pointer to threaded opcode (C procedure)>
<operand>
<pointer to threaded opcode (C procedure)>
<operand>
First some convenience defines:
#define TBEGIN {
#define TEND JUMPNEXT; }
All threaded opcodes begin with TBEGIN instead of { & TEND instead of }.
Here's a simple threaded opcode that pushes an operand onto the vm's stack:
void pushLit()
TBEGIN
*++stackPointer = (OOP)*tcip++;
TEND
JUMPNEXT jumps to the next threaded opcode. On mc68k its defined as
#define JUMPNEXT \
do{asm("mov.l (%a5)+,%a0; jmp (%a0)");return;}while(0)
and on sparc as
#define JUMPNEXT \
do{asm("ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7");return;}while(0)
JUMPNEXT is analogous to (*tcip++)(), but jumps instead of calls.
On a hypothetical pure C machine it could be:
#define JUMPNEXT return
So on the sparc pushLit is actually
void pushLit()
{
*++stackPointer = (OOP)*tcip++;
do{
asm("ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7");
return;
}while(0);
}
Which compiles to:
.global _pushLit
.proc 1
_pushLit:
!#PROLOGUE# 0
save %sp,-80,%sp
!#PROLOGUE# 1
add %g5,4,%g5
ld [%g7],%o0
st %o0,[%g5]
add %g7,4,%g7
ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7
ret
restore
Since each threaded opcode is jumping to the next we don't want the prolog or
the epilog. I apply the following sed-script to the assembler to strip them:
/^_.*:$/{n
N
N
s/ !#PROLOGUE# 0\n save %sp,[-0-9]*,%sp\n !#PROLOGUE# 1//
}
/ ret/d
/ restore/d
Which produces
.global _pushLit
.proc 1
_pushLit:
add %g5,4,%g5
ld [%g7],%o0
st %o0,[%g5]
add %g7,4,%g7
ld [%g7],%o0; jmpl %o0,%g0; add %g7,4,%g7
On the mc68k the sed-script is a little more involved but is still only 22
lines. (Its complicated because of the compiler optimizing various register
save/restore code. e.g. pushing a single register is quicker than using a
move multiple with a single bit set in the register move mask.)
All threaded opcodes run in the same stack frame. The system is kicked off
from a C routine that calls alloca to allocate a large enough stack frame
for all threaded opcodes, e.g.:
void Interpret()
{
tcip = init_tcode();
(void)alloca(1024);
(**tcip++)();
}
The resulting system is as efficient a threaded code interpreter as one
written entirely in assembler BUT
On the sparc
The system is about 20,000 lines (including comments)
All but 13 lines are ordinary C code.
12 lines are gcc-style global register variable declarations and
1 line defines JUMPNEXT (as above) with an asm statement.
42 lines of sed-script in 3 files
9 lines strip prolog/epilog from threaded opcodes
5 lines do a peephole optimization
28 lines restore a global register stomped on by .div & .rem
--
Eliot Miranda email: eliot@cs.qmw.ac.uk
Dept of Computer Science Tel: 071 975 5220 (+44 71 975 5220)
Queen Mary Westfield College ARPA: eliot%cs.qmw.ac.uk@nsfnet-relay.ac.uk
Mile End Road UUCP: eliot@qmw-cs.uucp
LONDON E1 4NSsmryan@garth.UUCP (sous-realiste) (07/31/90)
>of course, an undergraduate cs major could do it by themselves with a >copy of knuth in hand. >... >additive sequences, even middle square (just for illustrative >purposes) are all trivial (and portable) in hll's. berkeley's random How would you do (2^n)+1 modulo sequence on an n-bit machine in an HLL? Knuth describes how to do it in assembly, by intercepting the carry/overflow. -- Her somber eyes consider all ||/+\==/+\|| Steven Ryan that loom and tower, large and tall.||\=/++\=/|| ...!uunet!ingr!apd!smryan Her everyday is always new ||/=\++/=\||...!{apple|pyramid}!garth!smryan and fills her eyes of frail blue. ||\+/==\+/|| 2400 Geng Road, Palo Alto, CA
new@ee.udel.edu (Darren New) (08/15/90)
By not-very-popular demand, I have completed and posted to comp.sources.unix, comp.sources.amiga, and comp.binaries.amiga my Line Oriented Macro Expanders. This posting was prompted by the thread discussing why HHL's can't (or don't) support every operation the hardware can perform. Dr. Rubin was kind enough to describe to me one of the assembler-like statements that he needed translated into (for now) FORTRAN pseudo-calls. This motivated me to actually finish the darn thing and be done with it. I also built a macro description file (Rubin.mac) and a sample input file (Rubin.inp) that would translate the requested statements into something his FORTRAN compiler would handle; there are included them with the distribution. Anyway, look for it soon at a newsgroup/archive near you. -- Darren -- --- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---