[<<] [<] Page 1 of 1 [>] [>>] | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Subject:
Pic basic to asm translatore.
From: pic00 ####@####.#### Date: 17 Aug 2004 20:29:08 +0100 Message-Id: <41225C69.1010803@sourceforge.net> Hi, i want release the open source basic2asm translator for the pic processor. Currently, all the 12bit, 14bit and the 17xxx parts of the 16bit series are supported in addition to the scenix (now ubicom) cpu. The tool generates a binary file, with the possibility to view the ASM source. What is the binary output, that the tool should produce? hex, cod, or mcoff ? The reason for not using gpasm is the limited macro and preprocessor capability. 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. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
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 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
[<<] [<] Page 1 of 1 [>] [>>] |