gnupic: Pic basic to asm translatore.
Subject:
Re: Pic basic to asm translatore.
From:
Byron A Jeff ####@####.####
Date:
18 Aug 2004 22:33:38 +0100
Message-Id: <20040818213334.GA8861@cleon.cc.gatech.edu>
On Tue, Aug 17, 2004 at 09:28:41PM +0200, pic00 wrote:
> Hi,
> i want release the open source basic2asm translator for the pic
> processor.
Cool.
> Currently, all the 12bit, 14bit and the 17xxx parts of the
> 16bit series are supported in addition to the scenix (now ubicom) cpu.
So no 18F4330s yet then? No worries, I still need to write the picprg
addition for the 18F parts.
> The tool generates a binary file, with the possibility to view the ASM
> source.
> What is the binary output, that the tool should produce?
None. It should produce ASM source.
> hex, cod, or mcoff ?
None. It should produce ASM source.
> The reason for not using gpasm is the limited macro and preprocessor
> capability.
Two points:
1) The compiler shouldn't have need of the macro or preprocessor facilities
of the assembler.
2) If gpasm has limited facilities relative to MPASM (and I know of one
somewhat obscure limitation in that respect) then the right thing to do is file
a bug report and let's see if it can get fixed.
> Mcoff can be linked with gplink, but debugging capability is not
> supported with the gplink tool. External symbol files must be used
> in order to produce usable cod files for debugging.
> The cod file can be absolute or for linking. I don't know, if
> gplink can handle cod file as library files.
Which is exactly why the compiler should not produce a binary format. Since
you don't know what application your user is going to use in terms of the
binary in terms of format or linking, output the assembly and let the user
decide how they want to utilize it. You may want to create a shell script that
does some default thing, but you'll get more flexibility and a simpler tool
if you leverage gpasm and gplink.
BAJ
