From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Given Subject: Re: 8-bit Linux? Date: Wed, 28 Mar 2012 18:20:29 +0100 Message-ID: <4F73485D.50009@cowlark.com> References: <1332952418.67495.YahooMailClassic@web180810.mail.gq1.yahoo.com> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig2734858C2991BFF2E35E230B" Return-path: In-Reply-To: <1332952418.67495.YahooMailClassic@web180810.mail.gq1.yahoo.com> Sender: linux-8086-owner@vger.kernel.org List-ID: To: linux-8086@vger.kernel.org This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig2734858C2991BFF2E35E230B Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Chris Cureau wrote: > Very interesting! I'll look a little closer in a bit... >=20 > One of the nice things about the c128 is the built in MMU...which allow= s remapping of page 0 and page 1 (zero page and stack, respectively) at a= ny given moment. The same thing is possible with the 65816/65265 CPUs, w= hich are the next target. If you also use the o65 format, you can do sof= tware relocation. There are still limitations of course, but the barrier= s are lower given those things... Being able to remap the stack is a big win. Is 256 bytes a realistic C stack size, I wonder? I did some work a while back looking at ways of doing C on the 6502 and the Z80. They both suck, because both processors predate stack-frame-based languages, and so don't have any useful addressing modes (like stack-relative addressing). On the Z80 you have to copy sp into one of your precious 16-bit index registers, and then indirect each byte individually; at 4 bytes of code a byte, that's 8 bytes to read a single 16-bit value off the stack! On the 6502 it's even worse because of that fixed-position stack. Most compilers maintain their own C stack, with appalling performance results, of course. But if you *can* use the 6502 stack as the C stack, you can do something like this... stackaddr: // in zero page dw 0x0100 load_16_bit_value_at_sp_plus_a_into_xy: tsx stx stackaddr+1 tay ldx (stackaddr), y iny ldy (stackaddr), y That's nine bytes, unfortunately, but with luck you may be able to offset that by much more efficient parameter passing (as you can use pha/phx/phy to push values onto the stack). Plus, of course, if you were doing it for real you could arrange that the stack offset starts in Y rather than A, which would save you a byte. TBH, I thing the 6502 is such a poor match for C that it'd be better to compile to p-code (like a more advanced SWEET16); the improved code density should outweigh the performance issues for most tasks. I did actually do most of one a while back, with a Z80 interpreter, and had the ACK compiling to it, at least to a degree... I can dig it out if anyone cares. Alternatively you could write your programs in Fortran. The 6502 should run Fortran quite well. --=20 =E2=94=8C=E2=94=80=E2=94=80=E2=94=80 =EF=BD=84=EF=BD=87=EF=BC=A0=EF=BD=83= =EF=BD=8F=EF=BD=97=EF=BD=8C=EF=BD=81=EF=BD=92=EF=BD=8B=EF=BC=8E=EF=BD=83=EF= =BD=8F=EF=BD=8D =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 http://www.= cowlark.com =E2=94=80=E2=94=80=E2=94=80=E2=94=80=E2=94=80 =E2=94=82 "Parents let children ride bicycles on the street. But parents = do not =E2=94=82 allow children to hear vulgar words. Therefore we can deduce th= at =E2=94=82 cursing is more dangerous than being hit by a car." --- Scott A= dams --------------enig2734858C2991BFF2E35E230B Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9zSF0ACgkQf9E0noFvlzjrbACgkOrALqSaF6KlCaLg7FkCOE1g Uu4AoL83Z9uA5kFNIgUiM+/h/N8v9mFC =A2lE -----END PGP SIGNATURE----- --------------enig2734858C2991BFF2E35E230B--