glen@intelca.UUCP (05/20/84)
Is there any high-level language for a 6502 based machine that executes the final code quickly and efficiently? Recent discussions in net.micro.apple and net.micro.cbm seem to indicate: - No very efficient compilers exist - It is very difficult to write efficient compilers for the 6502 Most of the compilers for 6502 machines either: - compile down to an intermediate code which is eventually interpreted (For example: Apple Pascal compiles to p-code) - compile down to 8080/8085/Z80 code and require external hardware (For example: Turbo Pascal requires CP/M card) Neither case is a true, fast 6502 compiler. Jim Janney writes: From: janney@unm-cvax.UUCP Newsgroups: net.micro.apple,net.micro.cbm Subject: compilers for the 6502 Message-ID: <850@unm-cvax.UUCP> There have been a number of requests on the net for real (native code) C and Pascal compilers for the 6502, and a fairly noticeable lack of response. As it happens, I've been studying the 6502 recently and I've reached a conclusion that is now ready for beta-testing ("let's throw it onto the net and watch them kick it apart"), to wit: There will never be any good C or Pascal compilers for the 6502. Before you start organizing the mob of peasants with torches, allow me to explain. C and Pascal, and other similar languages, make extensive use of what C calls "automatic" variables. These are variables that are local to a particular function and have no existence outside it. Space is allocated for them when the function is entered and released again when the function is terminated. This is essential for recursion and allows better use of memory in general. This causes a problem for the 6502 in that these variables do not occupy fixed addresses: an address may be different for every call to the function. The usual solution is to express these addresses as offsets from an index register: when the function is called, all you have to do is put the right base address in the register and the code is ready to run. Unfortunately, although the 6502 has two 8-bit index registers and a zillion different ways for clever assembly language programmers to use them, it doesn't have any 16-bit index registers. So the usual solution doesn't work, unless you can live with a 256-byte address space. Worse, there don't seem to be any other good solutions. ... Jim Janney {{convex,ucbvax,gatech}!unmvax, {purdue,lbl-csam,cmcl2}!lanl-a}!unm-cvax!janney One language that seems to be fairly efficient according to net response is Manx Aztec C. They seem to have circumvented this problem as follows: Doug Gwyn writes: From: gwyn@brl-vgr.ARPA (Doug Gwyn ) Newsgroups: net.micro.apple,net.micro.cbm Subject: Re: compilers for the 6502 Message-ID: <2124@brl-vgr.ARPA> Manx C65 allocates automatics off the stack, as usual for C runtime design. However, they do not use the hardware stack since it is too limited but instead maintain their own (SP in a known place). This works just fine, although clearly a better architecture would permit faster, smaller code. **** OK, so Aztec C is fairly efficient, are there any other efficient languages for the 6502 (besides assembly)? Will there ever be? {The views expressed are soley my own and not necessarily those of my employer} ^ ^ Glen Shires, Intel, Santa Clara, Ca. O O Usenet: {ucbvax!amd70,pur-ee,hplabs}!intelca!glen > ARPA: "amd70!intelca!cem"@UCB-VAX \-/ --- stay mellow
reid@uwvax.UUCP (05/23/84)
I suggest you check out the Action! language available from OSS (Optimized Software Systems, I think). It was originally written for the Atari 800 (6502) but versions were supposed to become available for the Apple, etc. It compiles into very fast code, is prodecure-oriented, supports 16-bit (CARDinal or INTeger) variables as well as 8-bit BYTEs, supports pointers, arrays, standard I/O package, etc. The only major limitation I have found is that you can't nest function calls: Call1 ( Call2 ( X ) ). And you can'T recurse. But it sure beats anything else I've seen.... Glenn Reid ...seismo!uwvax!reid
brp@ihuxm.UUCP (B.R. Priest) (05/24/84)
<...> I don't see what al the fuss is about? What exactly do you want to do that needs to be faster? I have written several large applications on Apple computers using Apple pascal and the only real bottleneck I have encountered is Disk I/O. The solutions to that are hard disk or ram disk. Both are available. Given the limited memory space of the apple II series, I happily trade off the slower execution speed for the reduced size of P-Code vs compiled code. Better than swapping segments in and out all the time. Apple Pascal provides lots of low level built in functions and procedures if you need to speed up I/O. Other things that just have to be faster, can always be done with the assembler. Ben Priest AT&T Bell Labs Naperville IL !ihuxm -- !ihuxm!brp
tob@inuxa.UUCP (T Burger) (05/30/84)
There is a fast language for the 6502!!!!!!! A new language called ACTION! has been developed for the 6502. I have the version for the ATARI system. The syntax is a cross between C and pascal with the emphasis on pascal. Some of the nifty things in C are missing but on the whole the language isn't bad. YES it does compile to native 6502 code, and yes it excutes very fast. The compiler is also very fast This new language is supposed to be available for the apple machines also. A rumor abounds that it will be ported to the IBM-PC on its 8088. If you want a native code for the 6502 check it out. :q :wq