|
Hi All, Does anyone here use a meta-assembler or retargettable assembler? If not what is the expected form of software development - do you code directly in machine code or maybe create lots of macros in some other non-relevent assembler? Regards Sergio |
|
|
meta-assembler
Started by ●August 28, 2002
Reply by ●August 28, 20022002-08-28
|
>From: "Sergio Masci" <> >Reply-To: >To: <> >Subject: [fpga-cpu] meta-assembler >Date: Wed, 28 Aug 2002 15:04:08 +0100 > >Hi All, >Does anyone here use a meta-assembler or retargettable assembler? If not >what is the expected form of software development - do you code directly in >machine code or maybe create lots of macros in some other non-relevent >assembler? I used macros with the old Macro-80 assembler to create a cross-assembler for the TI 9995 processor, many years ago. It worked very well. This FPGA-based stack processor uses an assembler (SPASM) written in PERL: http://www.compusmart.ab.ca/rc/Papers/8bitprocessor/stackproc.html A table-driven assembler is another option, you can create tables for any instruction set. Cross-32 is a commercial one I've used, available from MPE, in Southampton, UK. There is a similar PD one on Simtel, I think. Leon -- Leon Heller, G1HSM Tel: +44 1424 14790 Email: My web page: http://webspace.webring.com/people/jl/leon_heller/ My low-cost Altera Flex design kit: http://www.leonheller.com _________________________________________________________________ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com |
Reply by ●August 28, 20022002-08-28
|
At 15:04 28/08/2002 +0100, you wrote: >Hi All, >Does anyone here use a meta-assembler or retargettable assembler? If not >what is the expected form of software development - do you code directly in >machine code or maybe create lots of macros in some other non-relevent >assembler? > >Regards >Sergio Retartable assemblers do exist but I have never used one. Your other methods are quite commonly used and to a large extent it comes down to how much code you have to write and where you are in the development cycle. Hand editing code works fine when you are testing individual instruction decode/execution in the VHDL simulator. Using an existing assembler with macros is also a well tested technique as it lets you write larger bits of code even if you cannot debug it in the rest of the tool chain. How well this works depends largely on the power of the macro language. If its not very flexible you end up with lots of macro's for the variants of the same instruction (eg addressing modes). I have on one occasion been able to map the instruction set of a small 16 bit processor onto the register set of a 68000 processor using macros and executed the 16 bit processor code in the instruction level simulator that the 68000 toolchain included. A bit wierd but you need all the help you can get! I would like to expand this question a little, if I may. 1. For the people who are developing "cpu's" what tool support do you typically have access to? e.g. Assemblers/linkers/instruction level simulators? 2. Where do you get them from? 3. How do you get code into your VHDL simulators? 4. How do you download code into your designs (i.e. bootstrap code)? For the custom processor designs/runtime systems I have worked on I have always generated an assembler, linker and instruction level simulator/debugger with a GUI. Obviously that was a lot of work the first time I did it but its much quicker the next time around since a lot of the code is common. The instruction level simulator always pays for itself as it allows up front code development and a reference platform for "correct" behaviour when trying to bring up the processor in hardware. Nick |
|
|
Reply by ●August 30, 20022002-08-30
|
--- In fpga-cpu@y..., Nick Terry <nickt@e...> wrote: > > At 15:04 28/08/2002 +0100, you wrote: > >Hi All, > >Does anyone here use a meta-assembler or retargettable assembler? If not > >what is the expected form of software development - do you code directly in > >machine code or maybe create lots of macros in some other non-relevent > >assembler? > > > >Regards > >Sergio > > Retartable assemblers do exist but I have never used one. Your other > methods are quite commonly used and to a large extent it comes down to how > much code you have to write and where you are in the development cycle. > > Hand editing code works fine when you are testing individual instruction > decode/execution in the VHDL simulator. > > Using an existing assembler with macros is also a well tested technique as > it lets you write larger bits of code even if you cannot debug it in the > rest of the tool chain. How well this works depends largely on the power of > the macro language. If its not very flexible you end up with lots of > macro's for the variants of the same instruction (eg addressing modes). I > have on one occasion been able to map the instruction set of a small 16 bit > processor onto the register set of a 68000 processor using macros and > executed the 16 bit processor code in the instruction level simulator that > the 68000 toolchain included. A bit wierd but you need all the help you can > get! > > I would like to expand this question a little, if I may. > > 1. For the people who are developing "cpu's" what tool support do you > typically have access to? e.g. Assemblers/linkers/instruction level simulators? > 2. Where do you get them from? > 3. How do you get code into your VHDL simulators? > 4. How do you download code into your designs (i.e. bootstrap code)? > > For the custom processor designs/runtime systems I have worked on I have > always generated an assembler, linker and instruction level > simulator/debugger with a GUI. Obviously that was a lot of work the first > time I did it but its much quicker the next time around since a lot of the > code is common. The instruction level simulator always pays for itself as > it allows up front code development and a reference platform for "correct" > behaviour when trying to bring up the processor in hardware. > > Nick 1,2 I am using the Telemark table driven macro assembler for our 16 bit embedded CPU, The tables are simple enough so that changing an instruction or addressing mode only takes a few minutes. The Telemark assembler runs on DOS or Linux and is shareware ($40 registration) 4. Since our processor runs out of blockram, we use the other port for downloading the program (cant do this as easily for data memory since we use both ports) I have a simple host download program that downloads a block of code, and then single steps and dissasembles the instruction stream (at the beginning of the pipeline), and displays the accumulator, carry, etc. The single stepper doesn't grok the pipeline (yet) so I have a bit of tape on the monitor screen that shows which instruction is about to be executed (hows that for high tech!) PCW |
