> What do you think of the orthogonality and reducing the semantic gap
> issue nowdays ? It seems like the second the RISC's and the good
I guess a more highly orthaognal architecture with fewer protruding
uglies would be in better taste- but with decent compilers the need
for it is somewhat less. Frankly, most of the x86's richness is
wasted on me at least- to be sure theres all these wonderful
instructions to do all sorts of esoterica, but I always seem to be
playing around getting data into the right registers. I do like the
architectures with lots of registers, even on RISC style hardware, I
think it could frequently save code space simply because there are
fewer constraints on the dataflows.
> it and had figured out all the nasty quirks of the tools for it. The target
> application also matters too, I cant imagine rendering postscript on a
> 8051 ;)
<<shudder>>, I'm doing some 8051 assembly now plotting points on a LCD
graphic panel, pixels packed into bytes, mapped to the display
controller. Then throw in the FP to get decent diagonal lines. Eww.
Its a home project so I don't have a decent compiler, just assembly
and Basic on a 12mc 8051AH. My current nightmare is the text mode
output, which is supposed to be independent of the dot graphics is
indeed printing properly, but the text data is appearing as garble in
the graphics display. Something about the address space assignments
of the text and graphics memory banks I'm pretty sure- but where where
where...
> ;)
> The 8051 at 12 Mhz, could pull about 1.5 mips from memory. So your PIC is a
> tad
> quicker. ;)
But the 8051 has external ram, our device has only internal RAM and
EPROM- so we're stuck at 8k code and 300 bytes or so RAM. Don't some
of the 8051 clones/derivatives make it up to > 40mc or so?
> needed. I've never worked on a big lisp system either. I'm not sure if it
> would be worse than a big 'C' system.
Well, when the Emacs people start talking about the OS acting as their
device driver, there must be prodigious wonders under the hood... One
of these days, I'll run into somebody who does AutoLisp programming
(AutoCAD's Lisp implementation)- I'm really curious about the design
approaches taken to get Lisp code to draw stuff.
> Dont you love it when a programmer important stuff and doesnt
> tell you. Or even better when a tool changes something for you without
> you asking for it to be changed.
But surely all those new features make it ever so much better, right??
;)
> Can you write a quick tool that takes the output of the compiler and
> automatically
> removes the redundant ram bank selects or is it hard to determine just which
> bank you are located at ???
Its a 2 pass macro assembler, the first generates assembly and the 2nd
feeds it into an assember. An optimizer could remove the redundant
bank selects, and the assembler would fix up the references, but the
damnable PIC architecture will cause trouble. It divides its 8k
address space into 4 2k pages, but code cannot flow over the page
division- the boundry must be jumped over. The 1st assembler pass
watches for this, bombing the compilation if the IP passes over a page
boundry. Thus I can't generate assembly output that exceeds its
address space, and then be optimized back into place. So, I think I'm
stuck. The assember people (Microengineering Labs) are very
responsive, I asked them about it and they are very aware of the
efficiency issues. As I'm sure you imagine, they have a list of
things to deal with in each release, but they say the efficiency will
improve (it has to some degree the past several releases).
> I was lucky we always had a 27256 or similar so 32k was a nice bunch of
> space
So roomy, and comfy! So what do you need all that space for, a
postscript interpreter or something? ;)
> and hardware engineer are gonna have to decode the stuff. Figuring out why
> a latch was polled when it doesnt seem necessary is never fun without good
Thats such a tough issue- I think its lots tougher than the same
scenario with regular PC software; its so much harder to understand
whats happening inside the processor, you often can't be sure if this
chunk of odd code is actually doing something important- either for
the app itself or the processor or the peripheral chips or.... Then
you go clean up the code- make it more efficient you know, and bring
the whole thing to a crashing wreck. I'm glad I won't be the one
dealing with that little nightmare.
Gregm