Assembler for PicoBlaze in Perl

I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 
for all of my test cases (including quite a complex program with over 
600 instructions). It is a full syntax checker (somewhat more lenient 
than the distributed KCPSM3.EXE), as well as a generator of all the 
files (vhdl and verilog templates, .dec, .hex, .m, and .log files). The 
main features are:
- platform independence (perl distributions are available for all the 
major OSs)
- will support mutiple source files
- will support filenames over 8 characters
- not all template files are required, and can have other names than 
ROM_form.*
- generation of ChipScope token files

I'd like to make a call for test cases, or potential users. Please email 
me if you're at all interested.  It's possible that this script may be 
included in future distributions of PicoBlaze.

Thanks,

Mike Peattie
-- 
--
-- Please ignore the reply to address, and use
-- mike -dot- peattie -at- xilinx -dot- com
--

Hi Mike,

Mike Peattie wrote:
> I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 

[snip]

> I'd like to make a call for test cases, or potential users. Please email 
> me if you're at all interested.  It's possible that this script may be 
> included in future distributions of PicoBlaze.

I could be interested in this - but mostly from the perspective of using 
it as a base to port the assembler into C.

I have some done some experiments with arrays of picoblazes connected to 
a central microblaze (running uClinux of course), with the microblaze 
dynamically reprogramming and communicating with the Picoblazes, 
scheduling tasks on them and things like this.  Currently I have to 
assemble the picoblaze code on a desktop machine, and just download the 
.bin files from the microblaze to the pico-nodes.

I could run perl on the microblaze then use your scripts on top of that, 
but it would be pretty heavy-weight - a direct C implementation would be 
much smaller.  I've never written an assembler, maybe it's time to try!

Regards,

John

John Williams wrote:
> Hi Mike,
> 
> Mike Peattie wrote:
> 
>> I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 

> I could be interested in this - but mostly from the perspective of using 
> it as a base to port the assembler into C.

I have a beginning here:

<ftp://ftp.icarus.com/pub/eda/pbasm/>

The assembler structure is there, it only needs some missing
pseudo-ops implemented and a few missing instructions filled
into a table.

-- 
Steve Williams                "The woods are lovely, dark and deep.
steve at icarus.com           But I have promises to keep,
http://www.icarus.com         and lines to code before I sleep,
http://www.picturel.com       And lines to code before I sleep."

John Williams <jwilliams@itee.uq.edu.au> writes:

> Hi Mike,
> 
> Mike Peattie wrote:
> > I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's
> > working
> 
> [snip]
> 
> > I'd like to make a call for test cases, or potential users. Please
> > email me if you're at all interested.  It's possible that this
> > script may be included in future distributions of PicoBlaze.
> 
> I could be interested in this - but mostly from the perspective of
> using it as a base to port the assembler into C.

Isn't there a GNU assembler for PicoBlaze?

Petter

-- 
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

John,
It's a piece of cake with Perl. I used a text file to hold the text of all
the Perl regular expression searches for the opcodes along with bits of Perl
source code text to convert that particular opcode into machine code. In the
code proper I just read in the text file to an array, and then use the
'eval' instruction to execute the elements of the array. (A big advantage of
an interpreted language!) Once I sussed this out, it took me about 2 hours
to rewrite my custom assembler; the original version was bug ridden and
taking ages. Not bad for a hardware engineer!
If you know the processor well, and have used Perl with REs before, you
could write one for Picoblaze in a morning, no worries.
Cheers, Syms.
"John Williams" <jwilliams@itee.uq.edu.au> wrote in message
news:clha4r$fd8$1@bunyip.cc.uq.edu.au...
>   I've never written an assembler, maybe it's time to try!
>

John Williams wrote:
> Hi Mike,
> 
> Mike Peattie wrote:
> 
>> I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 
> 
> [snip]
>> I'd like to make a call for test cases, or potential users. Please 
>> email me if you're at all interested.  It's possible that this script 
>> may be included in future distributions of PicoBlaze.
> 
> 
> I could be interested in this - but mostly from the perspective of using 
> it as a base to port the assembler into C.
> 
> I have some done some experiments with arrays of picoblazes connected to 
> a central microblaze (running uClinux of course), with the microblaze 
> dynamically reprogramming and communicating with the Picoblazes, 
> scheduling tasks on them and things like this.  Currently I have to 
> assemble the picoblaze code on a desktop machine, and just download the 
> .bin files from the microblaze to the pico-nodes.
> 
> I could run perl on the microblaze then use your scripts on top of that, 
> but it would be pretty heavy-weight - a direct C implementation would be 
> much smaller.  I've never written an assembler, maybe it's time to try!

Can you elaborate on what the Microblaze does, with these picoblaze 
source(s) ?
Does it create the sources, or modify 'master copies', prior to assembly ?
  How much resource does the Microblaze work with, uClinix
suggests MBytes of FLASH/DRAM ?

Assemblers, expecially ones minus linkers, can have quite small 
footprints, and there are many examples out there.

A good one to start with ( much closer than pearl scripts, but they 
would be tapped for the opcode info ), would be AS, see
http://john.ccac.rwth-aachen.de:8000/as/download.html

-jg

Hi Jim,

Jim Granville wrote:
> John Williams wrote:
> 
>> Mike Peattie wrote:
>>
>>> I have written an assembler for PicoBlaze (KCPSM3) in Perl. It's working 
>>
>>
>> I could be interested in this - but mostly from the perspective of 
>> using it as a base to port the assembler into C.
>>
>> I have some done some experiments with arrays of picoblazes connected 
>> to a central microblaze (running uClinux of course), with the 
>> microblaze dynamically reprogramming and communicating with the 
>> Picoblazes, scheduling tasks on them and things like this.  Currently 
>> I have to assemble the picoblaze code on a desktop machine, and just 
>> download the .bin files from the microblaze to the pico-nodes.
>>
>> I could run perl on the microblaze then use your scripts on top of 
>> that, but it would be pretty heavy-weight - a direct C implementation 
>> would be much smaller.  I've never written an assembler, maybe it's 
>> time to try!
> 
> Can you elaborate on what the Microblaze does, with these picoblaze 
> source(s) ?

The picoblaze program code, input and output data streams, interrupt and 
reset signals, are all mapped as virtual files within the uClinux file 
system.  So, on the Microblaze uClinux system, you can just cat a 
picoblaze hex (or bin) file into /proc/picoblaze0/code, and that 
reprograms the picoblaze.

It's pretty neat, I wrote a paper about it for the Field Programmable 
Technology (FPT) conference we are hosting here in December (plug plug!)

http://icfpt04.itee.uq.edu.au

If you're interested in the gory details let me know and I'll send you a 
preprint.

> Does it create the sources, or modify 'master copies', prior to assembly ?

Currently I just create bin/hex files of the picoblaze object code on 
the host, then get them down to microblaze somehow (ftp, http, telnet, 
whatever).  Then, once they are on the microblaze, the program code is 
just CAT'd into the virtual files like I described above.

>  How much resource does the Microblaze work with, uClinix
> suggests MBytes of FLASH/DRAM ?

Recommend bare minimum is 2MB but preferably 4MB or more external RAM. 
Flash is useful for holding the kernel and filesystem image, and also 
for persistent storage if you need it (all the standard linux file 
systems are available, jffs2, fat, ext2/3, whatever you prefer).

> Assemblers, expecially ones minus linkers, can have quite small 
> footprints, and there are many examples out there.
> 
> A good one to start with ( much closer than pearl scripts, but they 
> would be tapped for the opcode info ), would be AS, see
> http://john.ccac.rwth-aachen.de:8000/as/download.html

Thanks for the tip.  It's a fun architecture - I'd love to get the 
picoblaze assembler hosted on microblaze.  In fact, integrating the 
assembler into the device driver that handles the interface, you could 
pipe picoblaze assembly files directly into the virtual file, and it 
would automatically assemble it, and reprogram the picoblaze - too much 
fun! :)

John

Hi Symon,

Symon wrote:
> It's a piece of cake with Perl. I used a text file to hold the text of all
> the Perl regular expression searches for the opcodes along with bits of Perl
> source code text to convert that particular opcode into machine code. In the
> code proper I just read in the text file to an array, and then use the
> 'eval' instruction to execute the elements of the array. (A big advantage of
> an interpreted language!) 

Sounds like a good way to go - another feature of perl and similar 
languages that I like is associative arrays - having arbitrary strings 
as indices into arrays can sometimes make the world of difference.

Cheers,

John

John Williams wrote:

> Hi Jim,
> 
> Jim Granville wrote:
>> Can you elaborate on what the Microblaze does, with these picoblaze 
>> source(s) ?
> 
> 
> The picoblaze program code, input and output data streams, interrupt and 
> reset signals, are all mapped as virtual files within the uClinux file 
> system.  So, on the Microblaze uClinux system, you can just cat a 
> picoblaze hex (or bin) file into /proc/picoblaze0/code, and that 
> reprograms the picoblaze.
> 
> It's pretty neat, I wrote a paper about it for the Field Programmable 
> Technology (FPT) conference we are hosting here in December (plug plug!)
> 
> http://icfpt04.itee.uq.edu.au
> 
> If you're interested in the gory details let me know and I'll send you a 
> preprint.
> 
>> Does it create the sources, or modify 'master copies', prior to 
>> assembly ?
> 
> 
> Currently I just create bin/hex files of the picoblaze object code on 
> the host, then get them down to microblaze somehow (ftp, http, telnet, 
> whatever).  Then, once they are on the microblaze, the program code is 
> just CAT'd into the virtual files like I described above.
> 
>>  How much resource does the Microblaze work with, uClinix
>> suggests MBytes of FLASH/DRAM ?
> 
> 
> Recommend bare minimum is 2MB but preferably 4MB or more external RAM. 
> Flash is useful for holding the kernel and filesystem image, and also 
> for persistent storage if you need it (all the standard linux file 
> systems are available, jffs2, fat, ext2/3, whatever you prefer).
> 
>> Assemblers, expecially ones minus linkers, can have quite small 
>> footprints, and there are many examples out there.
>>
>> A good one to start with ( much closer than pearl scripts, but they 
>> would be tapped for the opcode info ), would be AS, see
>> http://john.ccac.rwth-aachen.de:8000/as/download.html
> 
> 
> Thanks for the tip.  It's a fun architecture - I'd love to get the 
> picoblaze assembler hosted on microblaze.  In fact, integrating the 
> assembler into the device driver that handles the interface, you could 
> pipe picoblaze assembly files directly into the virtual file, and it 
> would automatically assemble it, and reprogram the picoblaze - too much 
> fun! :)

  Thanks for the overview -  Interesting ideas - I can see version 
control benefits, and a little core-tolerance in handling ASM files over 
OBJ(Bin/hex) files.
  Plus ASM files allows more scope to customise prior to assemble
as well as being much easier to trouble shoot!

  Smallest Assemblers were ~20KB, and current HLL ones are ~ 45KB in 
EXEs, so that's not too large an overhead in a uClinix space.

  You probably should look at doing both PicoBlaze and MicroBlaze ASM 
versions :) - IIRC with the AS assembler, you can choose which variants 
to build.

  With some care in neumonics, you could target a PB source code, to
either PB or MB ?

  -jg