Article 42006 of comp.sys.cbm: Xref: undergrad.math.uwaterloo.ca comp.sys.cbm:42006 Newsgroups: comp.sys.cbm Path: undergrad.math.uwaterloo.ca!csbruce From: csbruce@ccnga.uwaterloo.ca (Craig Bruce) Subject: Re: Suggestions for ACE: Let's have a GUI! -- the author speaks Message-ID: Sender: news@undergrad.math.uwaterloo.ca (system PRIVILEGED account) Nntp-Posting-Host: ccnga.uwaterloo.ca Organization: University of Waterloo, Canada (eh!) References: <42ntic$3n9@odin.diku.dk> Date: Fri, 8 Sep 1995 16:05:21 GMT In article <42ntic$3n9@odin.diku.dk>, Jonas Olsen writes: >Hmm, if this is the attitude, then I fear that ACE will never be ready for >bells and whistles. The text editor and terminal program you're developing >are applications in my view, and thus not really a part of ACE as such. But, >I agree further work is needed on ACE before it's a full-blown devel- >opment enviroment. Text editors and terminal programs are generally considered to be system software. > In my view, the assembler is still the weakest link: > >- Macros are a must in a real assembler. >- #include statement >- .data statement >- Conditional assembly >- True expressions with operator-precedence instead of the current cludge That is "kluge". However, I personally don't think that it's very important for an assembler to have operator precedence. I certainly have no need for it. Can you show me a couple of examples where you have found it convenient to use expressions where operator precedence was required? >I don't think the one-pass relocation-project is that important. You will >only need it when you compile the "final" binary, and hence it doesn't >matter if you have to compile in two passes. You will never be able to >develop an assembler that garantees true relocation with respect to >expressions such as > > lda #(>label)/2+5 The "one-passness" of the assembler is already fully implemented. Also, I contend that your example is meaningless garbage and will never be used. The relocation mechanism will always work for non-meaningless label references. However, on a more theoretical level, it IS possible to relocate the above expression. What you have to do is save the full expression and have the loader evaluate the expression with the new value of "label" and poke the results into the reference hole. >and therefore I suggest limiting the efforts to the difference scheme >where you compile your program with two different base-addresses and >afterwards compares the binaries to find the locations that change. If some >of these locations doesn't change linearly, the program could output >a warning, and the programmer should inspect his code for non-simple- >relocatable code, and produce such. The difference mechanism would not be able to handle the above example expression either. >That's nice, and the way to go. And I think we all agree that a GUI for >ACE would be an add-on, although this means that we abandon the idea of >an integrated enviroment. I don't see why this means that we abandon an integrated environment. >Just tossing the ideas into the arena, How about tossing some code into the arena too? Keep on Hackin'! -Craig Bruce csbruce@ccnga.uwaterloo.ca "No cause too high, no tactic too low."