Re: Idea: Multitasking graphical OS for the GS
- From: "geoff" <geoff@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 8 Jan 2009 22:24:23 -0600
To: mdj
It depends on what the final goal is. If one is looking for an open source
(i.e. no commercial cost) IIgs 65816 compiler that has nearly the number of
users approaching zero, then might as well use the existing port of lcc which
has been around for over ten years. It too would need an OMF linker for
developing IIgs object code.
If the goal is to have a development environment immediately compatible with
many other operating systems with a large source base (configure; make
install) then gcc (and tools such as ld, gas, etc) would provide an
advantage--many new applications can be added in a very short amount of time.
And developers can cross-develop their apps to multiple operating systems,
ensuring a larger user base to use what they write.
gcc also has a much larger support infrastructure where it will be easier to
find assistance when there is a problem--the answer will most likely already
be in Google.
I know I had gotten gas to assemble 65816 with binutils. I had used a release
where one of the notes commented that 65816 support would be discontinued if
someone didn't pick up ownership. I didn't spend looking at any time with
current source to see if anything was removed. If something which existed
before and is gone now, then it can be recovered from an older revision in
CVS.
Once I figure out how to write SPEC files, I can put one together to show
that a cross-build binutils for the IIgs can be made as an installable
package.
Orca/C, lcc, 65cc would have the same exact bank limits as gcc. This can be
overcome to assume all addressing be absolute long (and add a special case to
JML to a new bank when you are at the end of the current bank). Long
addressing adds one cycle count for the instruction, but overcomes the 64k
bank limit. The optimizer can do the magic to use absolute addressing to
improve performance. The demand for a 20MHz accelerator won't be there until
there is software which requires it. The software developer and the hardware
developer are in a symbiotic relationship to ensure that there is user support
for one another.
Geoff
On Jan 8, 1:39=A0am, David Schmenk <dschm...@xxxxxxxxxxxxx> wrote:
The only support I could find is limited to the BFD files which provide
fixups to object files (coff in the w65 case). =A0Although useful, it
falls far short of the CPU support files needed by the assembler and
compiler. =A0The pseudo segmented architecture of the 65816 might be an
issue for gcc as well. =A0I looked a little at the CPU support
requirements for gcc; it doesn't look impossible but would be a bit of
work. =A0And then there is the OMF support that Geoff talks about below.
It could be that a different compiler would be a better starting point
for a 65816 version. =A0Perhaps cc65 or sdcc? =A0Or, someone who has
implemented a backend for gcc could jump in and do it in a day :-)
An OMF linker for cc65 would seem to be the easiest option. The only
catch being you only get a subset of ANSI C, and the '816 is easily capable
of hosting the complete language
Matt.
- References:
- Prev by Date: Re: Beagle Bros Tip Book #1
- Next by Date: Re: Not your father's Applicard
- Previous by thread: Re: Idea: Multitasking graphical OS for the GS
- Next by thread: Re: Idea: Multitasking graphical OS for the GS
- Index(es):
Relevant Pages
|
