From: Masur J. <jm...@bl...> - 2012-09-02 21:25:01
|
Hello, I am an active developer on the Nintendo Entertainment System platform, and currently I write all my programs in assembly language. Because this is long and ask for more work than writing programs in C, I am looking forward for a C compiler which can output optimized 6502 machine code. CC65 already exists, however it outputs unoptimised code which is too slow and too big compared to what it could be. On a system with very little ROM and RAM and with a slow CPU, this is not always acceptable. Therefore I wanted to explore the possibility to add support for the 6502 to SDCC. I don't know exactly where to start. I am unfortunately not experienced in writing compilers, however I am experienced with 6502 assembly and I am also experienced with the C language. I would greatly appreciate if someone could point me to the official procedure that should be followed in order to add a processor target to SDCC. Sincerely. |
From: Dave M. <mc...@ne...> - 2012-09-02 21:51:21
|
I cannot offer any assistance at the moment, but I would like to state that I would applaud the addition of a 6502 target for SDCC. -Dave On 09/02/2012 05:24 PM, Masur Jonathan wrote: > Hello, > > I am an active developer on the Nintendo Entertainment System platform, > and currently I write all my programs in assembly language. Because this > is long and ask for more work than writing programs in C, I am looking > forward for a C compiler which can output optimized 6502 machine code. > > CC65 already exists, however it outputs unoptimised code which is too > slow and too big compared to what it could be. On a system with very > little ROM and RAM and with a slow CPU, this is not always acceptable. > Therefore I wanted to explore the possibility to add support for the > 6502 to SDCC. > > I don't know exactly where to start. I am unfortunately not experienced > in writing compilers, however I am experienced with 6502 assembly and I > am also experienced with the C language. > > I would greatly appreciate if someone could point me to the official > procedure that should be followed in order to add a processor target to > SDCC. > > Sincerely. > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > -- Dave McGuire, AK4HZ New Kensington, PA |
From: Philipp K. K. <pk...@sp...> - 2012-09-03 04:33:57
|
On 03.09.2012 06:24, Masur Jonathan wrote: > Hello, > > I am an active developer on the Nintendo Entertainment System platform, > and currently I write all my programs in assembly language. Because this > is long and ask for more work than writing programs in C, I am looking > forward for a C compiler which can output optimized 6502 machine code. > > CC65 already exists, however it outputs unoptimised code which is too > slow and too big compared to what it could be. On a system with very > little ROM and RAM and with a slow CPU, this is not always acceptable. > Therefore I wanted to explore the possibility to add support for the > 6502 to SDCC. > > I don't know exactly where to start. I am unfortunately not experienced > in writing compilers, however I am experienced with 6502 assembly and I > am also experienced with the C language. I suggest you have a look at the sdcc source code, in particular exisiting ports. I would recommend the hc08 port, since that seems to be an architecture that is mroe similar to the 6502 than others supported by sdcc. A port consists of a few main components and some glue code. 1) Assembler 2) Linker 3) Simulator 5) Code generator 6) Peephole optimizer. For 1 and 2 there probably are exisiting ones that can be used. 3 is probably best to write based on ucsim, as most sdcc simulators are. 5 is most of the work. 6 should be postponed until after the port passes regression tests. You also need to think about how to do things. The 6502 unfortunately seems to be a very limited architecture (awkward stack access, small stack). Philipp |
From: Masur J. <jm...@bl...> - 2012-09-04 18:56:07
|
Thank you for your answer, I'll have a look at the existing ports and try to understand the existing ports. Their code is quite long and complex, so it'll be a pretty big project. Of course lots of 6502 assemblers and linkers already exists, I just don't know if specific ones needs to be made for a proper SDCC port. Anyways the hardest part is of course generating assembly from C and optimizing it so it's almost as good as hand-written assembly. This could probably be done without actually assembling/linking the result for the testing phase. Just like any other architecture, the 6502 is only limited to the RAM/ROM and clock rate it gets attached to on hardware. It is true it has only 3 8-bit registers, and only one of them (the accumulator) can handle mathematical operations, while the other two (X and Y) are used for indexing or temporary storage. However, most mathematical operations can also be done directly on memory, therefore memory can be used as additional registers. The stack is up to 256 bytes long, I'm not sure if that's considered "small" but I never came close to using all of it in my (assembly) programs. Now when you need to have a really optimized program the only way is usually to write down several variants of it, count the bytes/cycles of every variant, and retain the shortest or fastest one. I've done this many times. This process could probably be automated easily though, which would make a very good compiler ! The existing 6502 compiler, CC65, creates a software stack for the argument stack, and access it using a complex addressing mode. Another shareware compiler whom I've tried the trial version seemed to use a similar strategy. Unfortunately this is very slow and unoptimal. I've already contacted the authors begging them to change this strategy but they replied they wouldn't do it, and that I could always use static variables to avoid using an argument stack. Unfortunately this affects the readability of the C code. I am under the impression this is exactly what SDCC does - not using an argument stack for maximal code optimisation - at the cost to not being able to write re-entrant functions. But this is a very small price to pay for something that can result in code which is 2x faster and smaller too. The other alternative would be to make an unofficial version of CC65 implementing what I'd like to, the problem would be that when they update the real CC65 it'll be hard to update the unofficial version as well. A proper SDCC port would be more work, but in the end it would end up more maintainable. Well, I'm sorry for the very long message. Hopefully someone can point me to the "official" procedure to make a SDCC port while I'm studying the internals of SDCC. Regards. Le 03.09.2012 06:33, Philipp Klaus Krause a écrit : > On 03.09.2012 06:24, Masur Jonathan wrote: > > I suggest you have a look at the sdcc source code, in particular > exisiting ports. I would recommend the hc08 port, since that seems to be > an architecture that is mroe similar to the 6502 than others supported > by sdcc. > > A port consists of a few main components and some glue code. > > 1) Assembler > 2) Linker > 3) Simulator > 5) Code generator > 6) Peephole optimizer. > > For 1 and 2 there probably are exisiting ones that can be used. 3 is > probably best to write based on ucsim, as most sdcc simulators are. 5 is > most of the work. 6 should be postponed until after the port passes > regression tests. > You also need to think about how to do things. The 6502 unfortunately > seems to be a very limited architecture (awkward stack access, small stack). > > Philipp > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Sdcc-user mailing list > Sdc...@li... > https://lists.sourceforge.net/lists/listinfo/sdcc-user > |
From: Masur J. <jm...@bl...> - 2012-09-05 10:19:59
|
Le 05.09.2012 09:32, Sebastien Lorquet a écrit : > Hello, > > It depends on the port. > > [...] > > For your port, you can have both (as for mcs51): functions flagged with > __reentrant will use the stack convention, the others will use the overlay > convention. > Yes, this sounds like the way to go. By default, the function are not re-entrant and are optimized, but if it's required that they are re-entrant the user is free to do it. > To write a new port, I don't think you need an official guide, just look at how > an existing port is called from the main code and integrated, and start a new > one in a new subfolder :) If I remember correctly, there's a big port_t > structure that you have to fill with the proper values and function pointers. > > Regards > Sebastien Thank you for pointing me to this. > Isn't the HC08 be similar enough to 6502? Apparently it is quite similar, but the HC08 has no Y register, but has a lot of added instructions the 6502 lacks. I'll really look at the HC08 port as a base for my attempt to port for the 6502. > Also, as a remark, the 6502 has a derivative, the 65C02; of which > there also exists variants with "secret" (more or less officially > supported) instructions. Exact, the 65C02 has some extra instructions. It is used in the TurboGraphix-16 / PC-Engine video game console. There is also the 65C816 which has a 16-bit mode and many extra instructions, which is used in the Super Nintendo Entertainment System (SNES) video game console. It would be great to port SDCC for all variants of the 6502 family, although I'm not too sure about 65C816 because it's not entirely a 8-bit CPU, it's more a fake 16-bit CPU. It's data bus is physically 8-bit, but the registers can be toggled between 8-bit and 16-bit, and the instructions behave differently depending on the used mode, which can turn out quite complicated - for example a subroutine call that is supposed to be done in 16-bit mode can crash the CPU if called in 8-bit mode and vice-versa. I don't know if this make it "eligible" for a SDCC port. At least the 6502 and 65C02 are eligible. > It might be also interesting to find out whether WDC > (http://www.westerndesigncenter.com/wdc/ ) would be interested to > support such a porting in some way... They already have a C compiler, and like I said, I tried the trial version and they apparently use an software argument stack with slow addressing modes like CC65, which I really dislike. Thanks for the support and regards. |
From: Philipp K. K. <pk...@sp...> - 2012-09-05 14:58:24
|
On 05.09.2012 19:19, Masur Jonathan wrote: > There is also the 65C816 which has a 16-bit mode and many extra > instructions, which is used in the Super Nintendo Entertainment System > (SNES) video game console. > > It would be great to port SDCC for all variants of the 6502 family, > although I'm not too sure about 65C816 because it's not entirely a 8-bit > CPU, it's more a fake 16-bit CPU. It's data bus is physically 8-bit, but > the registers can be toggled between 8-bit and 16-bit, and the > instructions behave differently depending on the used mode, which can > turn out quite complicated - for example a subroutine call that is > supposed to be done in 16-bit mode can crash the CPU if called in 8-bit > mode and vice-versa. I don't know if this make it "eligible" for a SDCC > port. >From a quick look at the manual, the 65C816 seems fine for a sdcc port, but it is too different from 6502 to have the two ports integrated. Maybe later if there is enough interest. IMO there are some more serious things that needs fixing first in sdcc than lack of ports. Philipp |
From: Vaclav P. <vac...@se...> - 2018-10-03 12:54:54
|
Hi Jonathan, how are your plans to support 6502 in SDCC going ? Last week I got to TurboGrafx-16 game console and currently thinking how to program it in C. My idea is to create HuCard with SD CARD and RAM. Simple bootloader chooses the game from SD card, loads it into RAM and runs it. This sounds really like long way so C compiler would be helpful. Regards, Vaclav Od: Masur Jonathan Komu: sdc...@li... Datum: 5. 9. 2012 12:23:08 Předmět: Re: [Sdcc-user] Adding support for the 6502 processor "> Isn't the HC08 be similar enough to 6502? Apparently it is quite similar, but the HC08 has no Y register, but has a lot of added instructions the 6502 lacks. I'll really look at the HC08 port as a base for my attempt to port for the 6502. > Also, as a remark, the 6502 has a derivative, the 65C02; of which > there also exists variants with "secret" (more or less officially > supported) instructions. Exact, the 65C02 has some extra instructions. It is used in the TurboGraphix-16 / PC-Engine video game console. " |
From: Alan C. <al...@et...> - 2018-10-03 21:51:11
|
> Last week I got to TurboGrafx-16 game console and currently thinking how to > program it in C. My idea is to create HuCard with SD CARD and RAM. Simple > bootloader chooses the game from SD card, loads it into RAM and runs it. The HuC is not quite a 6502. cc65 supports it sort of but the HuC weirdnesses do require some care and workarounds because it places the zero page at $20xx unlike a real 6502. That in turn breaks anything that assumes zp accesses and 00xx accesses end up on the same page. Alan |
From: Vaclav P. <vac...@se...> - 2018-10-04 08:18:32
|
Just one remark to this. Several years ago I ported SDCC (SVN version 5568) to ST7 and testing looked OK. I had a look and ST7 and 6502 are very similar architectures. Same A,X,Y registers. SP is 16bit for ST7, status bits are different, probably instruction set and boot vectors as well. So to start porting to 6502 from ST7 would be probably the quickest way. Vaclav " Hi Jonathan, how are your plans to support 6502 in SDCC going ? Last week I got to TurboGrafx-16 game console and currently thinking how to program it in C. My idea is to create HuCard with SD CARD and RAM. Simple bootloader chooses the game from SD card, loads it into RAM and runs it. This sounds really like long way so C compiler would be helpful. Regards, Vaclav " Apparently it is quite similar, but the HC08 has no Y register, but has a lot of added instructions the 6502 lacks. I'll really look at the HC08 port as a base for my attempt to port for the 6502. > Also, as a remark, the 6502 has a derivative, the 65C02; of which > there also exists variants with "secret" (more or less officially > supported) instructions. Exact, the 65C02 has some extra instructions. It is used in the TurboGraphix-16 / PC-Engine video game console. "" |
From: Sebastien L. <seb...@lo...> - 2012-09-05 07:34:38
|
Le 04/09/2012 20:55, Masur Jonathan a écrit : > I am under the impression this is exactly what SDCC does - not using an > argument stack for maximal code optimisation - at the cost to not being > able to write re-entrant functions. But this is a very small price to > pay for something that can result in code which is 2x faster and smaller > too. Hello, It depends on the port. the stack strategy is used in the pic ports, but the mcs51 uses an "overlay" strategy. One of my wishes is to have an optional overlay strategy for the pic port, because the stack-based code generated by the pic port is ugly (but highly usable, I won't blame it, this is difficult code). For your port, you can have both (as for mcs51): functions flagged with __reentrant will use the stack convention, the others will use the overlay convention. To write a new port, I don't think you need an official guide, just look at how an existing port is called from the main code and integrated, and start a new one in a new subfolder :) If I remember correctly, there's a big port_t structure that you have to fill with the proper values and function pointers. Regards Sebastien |
From: Jan W. <we...@ef...> - 2012-09-05 08:26:56
|
Isn't the HC08 be similar enough to 6502? Also, as a remark, the 6502 has a derivative, the 65C02; of which there also exists variants with "secret" (more or less officially supported) instructions. It might be also interesting to find out whether WDC (http://www.westerndesigncenter.com/wdc/ ) would be interested to support such a porting in some way... JW |
From: Groepaz <gr...@gm...> - 2012-09-05 10:52:18
|
On Wednesday 05 September 2012, Masur Jonathan wrote: > > Also, as a remark, the 6502 has a derivative, the 65C02; of which > > there also exists variants with "secret" (more or less officially > > supported) instructions. > > Exact, the 65C02 has some extra instructions. It is used in the > TurboGraphix-16 / PC-Engine video game console. err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but contains a bunch of rather specific extension which can not be found in any other CPU (eg block copy, paging support) an actual 65C02 can be found in the NES aka famicom :) that said, only the 6502 (and 6510) contains such "secret" (as in undocumented) instructions. the opcode matrix of the 65C02 is completely defined (and further undocumented instructions replaced by either NOP or actual new instructions) -- http://www.hitmen-console.org http://magicdisk.untergrund.net http://www.pokefinder.org http://ftp.pokefinder.org Physics is like sex: sure, it may give some practical results, but that's not why we do it. <Richard Feynman> |
From: Jan W. <we...@ef...> - 2012-09-05 12:12:58
|
During the years I came across chips designated 65C02 which did not have the bit manipulation etc. "new" instructions. Clearly, there were several second-sourcing companies, some of them might have chosen to designate a 6502-like design as "C" simply to stress the CMOS technology. Also, according to wikipedia, NES contains a derivative which lacks the BCD mode. http://en.wikipedia.org/wiki/Ricoh_2A03 All I want to say is that there are variants which should perhaps be considered when planning a 65x02 port. JW ----- Original Message --------------- Subject: Re: [Sdcc-user] Adding support for the 6502 processor From: Groepaz <gr...@gm...> Date: Wed, 5 Sep 2012 12:52:24 +0200 To: sdc...@li... >On Wednesday 05 September 2012, Masur Jonathan wrote: >> > Also, as a remark, the 6502 has a derivative, the 65C02; of which >> > there also exists variants with "secret" (more or less officially >> > supported) instructions. >> >> Exact, the 65C02 has some extra instructions. It is used in the >> TurboGraphix-16 / PC-Engine video game console. > >err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but contains >a bunch of rather specific extension which can not be found in any other CPU >(eg block copy, paging support) > >an actual 65C02 can be found in the NES aka famicom :) > >that said, only the 6502 (and 6510) contains such "secret" (as in >undocumented) instructions. the opcode matrix of the 65C02 is completely >defined (and further undocumented instructions replaced by either NOP or >actual new instructions) |
From: Masur J. <jm...@bl...> - 2012-09-05 14:29:40
|
Le 05.09.2012 12:52, Groepaz a écrit : > > err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but contains > a bunch of rather specific extension which can not be found in any other CPU > (eg block copy, paging support) > > an actual 65C02 can be found in the NES aka famicom :) > > that said, only the 6502 (and 6510) contains such "secret" (as in > undocumented) instructions. the opcode matrix of the 65C02 is completely > defined (and further undocumented instructions replaced by either NOP or > actual new instructions) > You are right - I assumed the PC-Engine Hu CPU was just a 65C02 with some extra hardware, but it appears to have custom instructions. The NES does not technically contain a 6502 but a 2A03 or 2A07 (NTSC/PAL), both of which contains the die of a regular 6502, lacking decimal mode as it was pointed out. Sounds like it will be more complicated than I expected to handle all these variants properly and to test them (assuming the goal is to produce the most efficient code possible on any given variant), but the plain 6502 is a must-start (since all other variants can run plain 6502 code just fine). |
From: Dave M. <mc...@ne...> - 2012-09-05 18:17:22
|
On 09/05/2012 06:52 AM, Groepaz wrote: > err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but contains > a bunch of rather specific extension which can not be found in any other CPU > (eg block copy, paging support) A 6502 with block copy and paging?? Wow. Are these chips available anywhere? -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: Groepaz <gr...@gm...> - 2012-09-05 18:29:16
|
On Wednesday 05 September 2012, Dave McGuire wrote: > On 09/05/2012 06:52 AM, Groepaz wrote: > > err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but > > contains a bunch of rather specific extension which can not be found in > > any other CPU (eg block copy, paging support) > > A 6502 with block copy and paging?? Wow. Are these chips available > anywhere? i dont think they were ever used anywhere except in the PCE :) -- http://www.hitmen-console.org http://magicdisk.untergrund.net http://www.pokefinder.org http://ftp.pokefinder.org I remember when "legal" used to mean lawful; now it means some kind of loophole. <Leo Kessler> |
From: Dave M. <mc...@ne...> - 2012-09-05 18:38:53
|
On 09/05/2012 02:29 PM, Groepaz wrote: > On Wednesday 05 September 2012, Dave McGuire wrote: >> On 09/05/2012 06:52 AM, Groepaz wrote: >>> err, no - the PCE uses a NEC "HuC6280" CPU, which is "6502 like", but >>> contains a bunch of rather specific extension which can not be found in >>> any other CPU (eg block copy, paging support) >> >> A 6502 with block copy and paging?? Wow. Are these chips available >> anywhere? > > i dont think they were ever used anywhere except in the PCE :) Crap. :-( They sound like fun. -Dave -- Dave McGuire, AK4HZ New Kensington, PA |
From: Gál Z. <tra...@fr...> - 2012-09-06 17:34:31
|
http://www.westerndesigncenter.com/wdc/w65c02s-chip.cfm I read that this chip is alive. |