rupp@cod.UUCP (William L. Rupp) (12/18/86)
A friend of mine who is an assembly language enthusiast tells me that 65C816 assembly language is rather more difficult than 65C02 assembly language due to the necessity of switching back and forth between 8 and 16 bit modes. His explanation was rather sketchy and preliminary, so I did not get a lot of detail. It had to do with the size of registers, I believe. I would appreciate any information regarding 65C816 assembly language difficulties on the Apple IIGS. If there are such difficulties, I wonder what that will mean for development of IIGS specific software.
ranger@ecsvax.UUCP (Rick N. Fincher) (12/19/86)
> > I would appreciate any information regarding 65C816 assembly language > difficulties on the Apple IIGS. If there are such difficulties, I wonder > what that will mean for development of IIGS specific software. I think that programming the 65816 is easier than programming the 6502. There are two modes, 8 and 16 bit. The 8 bit mode exists primarily to run older software. There is no real need to use it idf you use Prodos 16 . The only real limitation is the 64 bank switching scheme. It sort of reminds you of segments on the 8088, but it is not that restrictive. Some instructions (branches, for example) only work inside a 64K bank that is identified by the top two hex digits in the address. A gs monitor dump looks like 00/ffffFFFF, with the slash separating the bank address from the 64K address. Branches will wrap around inside a bank rather than going to the next bank. You can do direct addressing of any location, long jumps and long jumps to subroutines from anywhere in memory to anywhere else in memory. One new set of instructions is the stack relative set of instructions and addressing modes. These allow the programmer to load and store relative to addresses placed on the stack. These were added to make code completely relocatable, but will require a little study for a 6502 programmer to understand. A good book on the '816 is "Programming the 65816" by David Eyes (now working at Apple in //gs software tools development), published by Brady Books. It is a good reference for the entire 65xxx family. Another thing that will take some getting used to is the Prodos 16 memory management scheme. I don't have all of the details but I understand that it uses some sort of demand paging scheme. If your program requires 2 meg and your computer only has 512K it will switch out 64K banks as needed to disk. From what little I have heard it looks to the programmer much like the system the Mac uses (Thank God memory upgrades are easy!), but this is all rumor and hearsay, I haven't seen the tech manuals yet on Prodos 16. I think that the '816 is also easier to program because you can have multiple zero pages in the first 64K of memory as well as a much larger hardware stack. Except for some possible special applications with 8 bit quantities that may be more efficient in 8 bit mode, I don't see any reason to switch between the 8 and 16 bit mode on the //gs. Some people have been writing stuff on 65802 processors put in a //e for awhile, and in this case you have to switch back and forth to do I/O Prodos calls in 8 bit mode. The '816 comes up in the 8 bit mode for compatibility purposes, so the first thing you can do on a gs is switch into the 16 bit mode. I think you will like the power of the '816 once you get used to it, you won't want to go back to the restrictions of the 6502. Aim Flames at: Rick Fincher ranger@ecsvax
daveh@cbmvax.cbm.UUCP (Dave Haynie) (12/23/86)
> Keywords: IIGS, 65C816, assembly language, 8/16 bit modes > Summary: I think 65816 is easier... >> I would appreciate any information regarding 65C816 assembly language >> difficulties on the Apple IIGS. If there are such difficulties, I wonder >> what that will mean for development of IIGS specific software. > I think that programming the 65816 is easier than programming the 6502. > There are two modes, 8 and 16 bit. The 8 bit mode exists primarily to > run older software. There is no real need to use it idf you use Prodos 16 > The '816 comes up in the 8 bit mode for > compatibility purposes, so the first thing you can do on a gs is switch into > the 16 bit mode. I think you will like the power of the '816 once you > get used to it, you won't want to go back to the restrictions of the > 6502. > Aim Flames at: > > Rick Fincher > ranger@ecsvax *Minor incoming flames* While you probably understand the '816/'802 architecture better than your posting woul indicate, I thought I'd clear up a few things that appear misleading in your article, especially in reference to the weirdness of programming the chip that first surfaced in the original article. The first clarification I'd like to make is that of MODES. The '816 chip actually has two levels of modes. The first is what most folks refer to as the 8/16 bit mode change, but this is really misleading. What you really have is two modes, the 8 bit _emulation_ mode, in which things look like a cross between a 6502 and a 65C02, with extensions (8 bit only, pretty 6502 compatible), and the 8/16 bit _native_ mode, where older code will only work if you're lucky. The emulation mode is certainly for using older code only, and its about as 6502 compatible as a 65C02, even better in a few cases. Now we move to native mode. In native mode, there's a choice of submodes. You can make things 8 bits long, or 16 bits long. Both of these are important, and changing between them is generally regarded as the "weird" part of the '816 chip. A new bit in the status register indicates whether the accumulator is 8 or 16 bits wide. And this is very important. 'Cause just about ANY instruction I execute will need to know whether I want an 8 or a 16 bit operation to occur. If I'm dealing with characters, or perhaps some kinds of graphic screens, I'll choose the 8 bit mode. When I want to do integer math, I'll choose the 16 bit mode. The thing is, in either case, I'm using EXACTLY the same instructions. The effect of each instruction varies based in the setting of this mode bit. And of course, the reason its in the status register is interrupts: if I get an interrupt, the interrupt service routine will have to choose which mode it wants to run in. Changing the mode bit could have dire consequences on the code that was running before the interrupt. But since the bit-width bit is in the status register, its saved on an interrupt, and restored by RTI. Thus, there's no problem with interrupts. There is a difficulty, however, with an assembler. Lets assume, for instance, I want to code an instruction, say an LDA #$00 or something. A 6502 assembler would give me two bytes, one for the LDA instruction, one for the immediate data value of $00. Now we go into native mode. I get the same assembly if I'm in 8 bit mode, 2 bytes. But if I go to 16 bit mode, my LDA codes one op-code, plus 2 data bytes, since I'm loading a 16 bit value now. Thus, the output of the assembler MUST be based on the value of a flag that can be set at run time. This is extremely weird, and will really depend on the programmer to keep the Assembler honest. Note that other microprocessors handle the bit width problem by providing different op-codes. A 68000 will give you one op-code for a BYTE valued MOVE immediate (LDA # equivalent), one op-code for a WORD (16 bit) MOVE immediate, and one op-code for a LONG WORD (32 bit) MOVE immediate. No register width status bit to worry about. That's the problem with the 65C816 that everyone's wondering about these days. It doesn't prevent the '816 from being a useful chip, but it does make it a very non-conventional architecture which will certainly complicate programming of the thing. -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh Why look here for inspiration, when its all around you anyway. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ranger@ecsvax.UUCP (Rick N. Fincher) (01/05/87)
In article <1162@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > > Keywords: IIGS, 65C816, assembly language, 8/16 bit modes > > Summary: I think 65816 is easier... Dave, I agree with your comments, I misunderstood the gist of the 1st question. I think that folks who have programmed primarily on the 68000 and 80xx series will have some problems dealing with differences in the way the '816 does things. I have seen some assemblers that use the convention of changing from 8 to 16 bit registers with a macro call that the assembler implicitly changes the mode if necessary, basically they define their own byte and word mnemonics. This is not the way the ORCA assembler works, however, and it is the Western Design Center standard as well as Apple's. To me keeping track of what register width I'm using is a lot simpler than keeping track of, say, segments in the 8086 architecture, although the '816 is segmented, I find it much more straightforward. My mindset is that of someone who programs in assembler mostly on 65xx processors and only does 80xx when he has too. The 68000 is a Cadillac, but I think that beginning assembly language pro- grammers have trouble remembering all the mnemonics for byte word and long. It is undoubtedly a better way to go once you have committed all of the mnemonics to memory, however, since it avoids the ambiguity of the register width that you have with the '816. To me learning to program the '816 was a natural progression from the 6502, everything made sense, the only thing I considered 'weird' was the stack relative stuff because it was new on the 816, although this has been on other processors before. I see you point about 'weirdness' however, the register width mode switching is weird in that it is done in a completely different way from most processors. Thanks for the comments. Rick Fincher ranger@ecsvax >
daveh@cbmvax.cbm.UUCP (Dave Haynie) (01/14/87)
> Summary: I agree... > > In article <1162@cbmvax.cbmvax.cbm.UUCP>, daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >> > Keywords: IIGS, 65C816, assembly language, 8/16 bit modes >> > Summary: I think 65816 is easier... > Dave, > > To me keeping track of what register width I'm > using is a lot simpler than keeping track of, say, segments in the 8086 > architecture, although the '816 is segmented, I find it much more > straightforward. My mindset is that of someone who programs in assembler > mostly on 65xx processors and only does 80xx when he has too. Well, if I didn't have all of these great 68xxx based machines here to program on... But really, I prefer much of what 65816 Assembly language looks like, including its weirdness, than the 808X families. I have no desire to load a register and then have to explicitly compare it to zero, or any of the other quirky things you have to do on 808Xs. And the '816s segmentation looks much more reasonable and probably more powerful; certainly it has a usable addressing range (I don't consider 1 megabyte a usable maximum address range). > The 68000 is a Cadillac, but I think that beginning assembly language > programmers have trouble remembering all the mnemonics for byte word and > long. You mean, like .B, .W, and .L :-). But there certainly are more 68000 mnemonics, and many of them would be new to a 65XX programmer, who'd have little trouble upgrading to a 65816. I think the 808X would be very hard for the average 65XX programmer to pick up, since it does things so differently. > Rick Fincher > ranger@ecsvax -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "You can keep my things, they've come to take me home" -Peter Gabriel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
ln63wzb@sdcc7.ucsd.EDU (Greg Robbins ) (01/15/87)
In article <1226@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: >But there certainly are more 68000 >mnemonics, and many of them would be new to a 65XX programmer, who'd >have little trouble upgrading to a 65816. I think the 808X would be >very hard for the average 65XX programmer to pick up, since it does >things so differently. > >Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh I had to learn the 8086 last spring, then the 65816 last summer. I preferred the quirks of the '816 to those of the 8086 only because of prior familiarity with the 6502; going in cold, the '816 certainly doesn't offer significant advantages in ease of use over the 8086. In fact, it's kind of annoying to have to put up with the '816's quirks when the chip lacks the "power instructions" we expect in the latest, plushest microprocessors. The 8086 is, flexibility wise, in a class above the newer '816. What about the future, I wonder? Though Mensch/Western Design Center has announced plans for a 32-bit version of the 658XX, who really wants it? Unless you espouse orthogonality as a religion, and design your simplest processors from the start to be powerful machines temporarily hadicapped, trying to keep a family going for several generations for compatibility's sake gets real messy and unpleasant. I've heard little praise heaped upon the elegance of the 80X86 family design, for despite a noble heritage, it has hardly evolved into the programmer's dream machine of today. Apple still proclaims Apple II forever. I love the old machine, but it is old; most of the die hard Apple II programmers have gone on to the Mac. The IIgs seems more like the last gasp of a dying machine than a modern, competitive computer. Let's keep II emulation alive in our machines forever, but not pretend that it should be the core of future of personal computers. Grobbins ln63wzb@sdcc18.ucsd.edu ...sdcsvax!sdcc7!ln63wzb
ranger@ecsvax.UUCP (Rick N. Fincher) (01/15/87)
Most of what you say is a matter of personal preference and is not really
arguable, but I take exception to your contention that it is not useful
to extend the life of a processor by Kludgy upgrades. From a hardware
designer's point of view or a Computer Scientist's, it is certainly more
elegant to move to more modern architectures. You must remember, though,
that microcomputers have moved past the stage of being the tools of a few,
to being true mass market consumer items. When this state of affairs exists
you have to evaluate the impact of abandoning an obsolescent technology
in favor of a new 'better' technology. Who is this technology better for?
The consumer? Or the producer and the programmer? Sure more powerful
machines are great for programmers, but what about the 3 million or so
consumers out there who have Apples? Should 3 million be inconvienienced
so that a few thousand programmers won't have to work as hard to create
applications that are state of the art? What about the billions of
dollars the consumer has invested in peripherals and software? It's
as if you were to say "Current television technology is inferior, it
should be scrapped and a new system with much greater capability should
be implemented", you may be absolutely right on a technical level, but
on the level of what consumers care about, you would be wrong. People
in general don't know or care what's inside the box. All they know is
that they either like or dislike what the box produces. A bomb TV show
will still be a bomb on a Super-Duper 3-D Holographic TV set, where
something like the Cosby Show will be a hit on any TV set, and probably
Radio too, if that were all that we had to receive the show on. In order
to justify a complete change of technology, the consumer will have to
perceive that the new technology offers something so superior that it
would be worth losing the investment they currently have to get those
new capabilities. Improvements in speed or other capability of less
than orders of magnitude will be ignored. In order for a completely
new product to make it today, there has to be enough of a market of new
users getting their first system (people who want to get the best that
that is available) or users who currently have machines must perceive
that the new system offers them so much more than their old system that
they'd be foolish not to change. The //gs versus the Amiga is a case in
point. The Amiga is superior in many ways to the //gs, better faster
processor, hardware graphics support, multitasking operating system etc,
but it is inferior to the //gs in other ways, lack of cheap easy expandability,
lack of a wide selection of software, lack of built in networking and
perhaps most important, lack of an installed base large enough to make
developers risk money writing software for the machine.
As machines get better and faster current technology can be modified to
at least stay in the ball park. Of course all technology will eventually be
be replaced with something better, it is important for people like
Commodore to keep pushing the technology forward because eventually
the mass market will catch up with them, but it won't happen overnight.
Untill then the old stuff with a new twist will still be competitive to
the consumer, who is only concerned with end results. So I think it's
great that Bill Mensch is working on a 32 bit 65xxx. If the current
65816's start coming out in gallium arsenide at 100+ mhz then they will
hold their relative position, in terms of capability, to GA 68000's. I
hope to drop an accelerator board in the slot of my //gs when that happens
one day and run my existing software 30 times faster and wonder what
things will be practical that weren't before with all that extra speed.
Rick Fincher
ranger@ecsvax "Please give decent warning before firing up your
flamethrowers, so I can put on my flameproof suit :-)"
In article <853@sdcc7.ucsd.EDU>, ln63wzb@sdcc7.ucsd.EDU (Greg Robbins ) writes:ln63wzb@sdcc7.UUCP (01/17/87)
In article <2571@ecsvax.UUCP> ranger@ecsvax.UUCP (Rick N. Fincher) writes: > >... I take exception to your contention that it is not useful >to extend the life of a processor by Kludgy upgrades. [Argument that we cannot ignore the installed base of technology just for the sake of using the newest hardware, and that great things can still be derived from existing equipment.] >As machines get better and faster current technology can be modified to >at least stay in the ball park. Of course all technology will eventually be >be replaced with something better, ... but it won't happen overnight. >Until then the old stuff with a new twist will still be competitive to >the consumer, who is only concerned with end results. I hold my philosophical head in shame. I renounce my previous posting as having ignored the realities of the marketplace, and I concede your points on practical matters. Save for two: >[Unlike the IIGS, the Amiga suffers from lack of] cheap easy expandability, >lack of a wide selection of software, lack of built in networking and >perhaps most important, lack of an installed base large enough to make >developers risk money writing software for the machine. The IIGS doesn't have a big installed base, the II..//c do. How many developers want to use the new features of the IIGS and give up sales to the enormous number of II users? You'd get the same installed base attractiveness by giving the Amiga emulation ability. I'm bothered less by Apple's decision to continue the II line than by the small (considering the state of the art, and the machine's price range) step forward they took with it (sound capability excepted), and by their failure to provide a design intended to carry it into the future, beyond just bringing it up to date. (I hope to be proven wrong, but don't expect to be.) And the other thing... >something like the Cosby Show will be a hit on any TV set, and probably >Radio too, if that were all that we had to receive the show on. Cosby is a hit, but on radio it'd been seen as a notch below Cheers. (:-) Grobbins ...sdcsvax!sdcc7!ln63wzb
daveh@cbmvax.cbm.UUCP (Dave Haynie) (01/20/87)
> > What about the future, I wonder? Though Mensch/Western Design > Center has announced plans for a 32-bit version of the 658XX, who > really wants it? Unless you espouse orthogonality as a religion, > and design your simplest processors from the start to be powerful > machines temporarily hadicapped, trying to keep a family going for > several generations for compatibility's sake gets real messy and > unpleasant. I've heard little praise heaped upon the elegance of > the 80X86 family design, for despite a noble heritage, it has > hardly evolved into the programmer's dream machine of today. Well put. Of course, realize Mensch and his gang are the same ones who hope someday to build a 6502 in GaAs that'll run at 100MHz. So I never take them too seriously. At Commodore we received 65802 and 65816 chip samples over four years ago, but they would only run at 500KHz. It was only this past late summer/early fall that limited quantites of 4MHz parts were available, though the spec sheets still list parts all the way up to 8MHz. A 32 bit version is still going to really be an 8/32 chip, if the claims of pin compatibility are to be believed, with a maximum address range of 16Megabytes. I think WDC was lucky to get Apple committed to their new chip, but I'd really be surprised to see anyone use a future version of it, unless they change their design philosophy drastically and provide a real 32 bit mode that might emulate the 8 bit modes without much pain. And even at that, its an uphill fight, at least in the mass home and business markets, to oppose the latest and greatest from Motorola and Intel. AT&T, TI, National, etc. are all having their troubles with it. > Let's keep II emulation alive > in our machines forever, but not pretend that it should be the core > of future of personal computers. That's what I keep telling 'em about C64s, too. Modern computers, like 68000 and fast 80X86 types, should be able to emulate the old machines, or at worst run them with a cheap expansion card. The reasons to run this old stuff are becoming less and less obvious, as well. There's no going back for most people. > > > Grobbins > > ln63wzb@sdcc18.ucsd.edu > ...sdcsvax!sdcc7!ln63wzb -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dave Haynie {caip,ihnp4,allegra,seismo}!cbmvax!daveh "You can keep my things, they've come to take me home" -Peter Gabriel ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
schumann@puff.UUCP (01/27/87)
In article <853@sdcc7.ucsd.EDU>, ln63wzb@sdcc7.ucsd.EDU (Greg Robbins ) writes: > In article <1226@cbmvax.cbmvax.cbm.UUCP> daveh@cbmvax.cbm.UUCP (Dave Haynie) writes: > >[..] I think the 808X would be > >very hard for the average 65XX programmer to pick up, since it does > >things so differently. True. But once you start, it is a very powerful inst. set. > The 8086 is, flexibility wise, in a class above the newer '816. Nicely put. > What about the future, I wonder? Though Mensch/Western Design > Center has announced plans for a 32-bit version of the 658XX, who > really wants it? OK... Remember that a 65C02 running at a mere 2 MHz has a memory cycle that is as fast as an 808X running at 8MHz (an 808X takes four clks per memory fetch). This is what pipelined architecutre does (NOT an instruction pipeline).