Picoblaze enhencement and assembler

Hi,

I wasn't very satisfied with the available assembler, so a few month
ago I wrote a new compiler for the Picobaze during my spare
weekends ...

I just though I'd share it if anyone is interested ....

It's available there :
  http://www.246tnt.com/files/PBAsm_20080225.tar.bz2

Example usage:
 python ./Codegen.py example.S out.mem

WARNING: The last file on the command line is the output ... so if you
forget it, it will overwrite your last source file ...

What are the pro and cons:

pros:
 - Cross platform
 - It supports local label, so for labels that don't really deserve a
name you can do things like

    load s0, 15
1:
    sub s0, 1
    jump nz, 1b

   And the '1b' reference says to find the first label named 1 when
going 'back' (1f would be forward...).
   Local labels are just a single digit.

 - It supports initialized data, and reference to the "data" sections.
Like

.data
var1: .byte 0xa5

.text
load s0, var1
fetch s0, (s0)

 - It supports evaluating expression like "load s0, 15 / 5 * 8"
 - It supports some advanced hw feature not in the original picoblaze
like offset during fetches / store / input / output :

fetch s0, (s1)8

equivalent to

add s1, 8
fetch s0, (s1)
sub s1, 8

but in 1 cycle and at no hw cost ... (just need to change a LUT3 to a
LUT4 and change it's INIT string)


cons:

 - Incompatible syntax with the official one ...
 - I haven't tested interrupt stuff
 - The registers are now s0 -> s15 and not s0 -> sF ... (easier to
parse)
 - To use all the features you need a hw modified picoblaze
 - It has terrible error reporting ... basically just throws an
exception with a not always helpful message.

It could use cleanup, an optimizer, a C front-end, a macro
preprocessor .... but ... it works :)

About the hw mods to the hw :
 - I removed the ScratchPad distributed RAM and used the second port
on the BRAM as scratch pad. The second port is configured as 8 bit
width and with upper address lines mapped to 1 so that the SP is
located at the end of the BRAM. (Be careful when playing with this and
interruptions, the last 2 bytes of the scratch pad is the interrupt
vector ...) And the bonus is a 256 byte scratch pad, just sacrificing
128 instruction words ... (adjust mapping for other tradeoffs)

  This mod is not absolutely needed. But if you want to use the pre-
initialized memory without it, you'll have to change the main function
to output two independent .mem file instead of just 1 merged one ...
(pretty easy, juste look at the end of CodeGen.py )

 - I changed a lut to allow for having an offset in fetch/store/input/
output ... I can post the exact patch if it's to interest to anyone.
(I don't have it handy right here ...) But it doesn't cost any
slice ... It might prolong the critical path a bit. But for me, the
critical path was somewhere else anyway so I didn't mind ...


Sylvain

>  - Cross platform

I forgot to say you need Python and also the Ply (Python Lex Yacc)
library ...

Sylvain Munaut <SomeOne@SomeDomain.com> wrote:
> Hi,
> 
> I wasn't very satisfied with the available assembler, so a few month
> ago I wrote a new compiler for the Picobaze during my spare
> weekends ...

Hi Sylvain,

Nothing to add but encouragement really. The software offerings for 
picoblaze are limited, especially in the non-windows world. Both picoasm 
and kpicosim are very good, but their development seems to have stopped.

If you can get a polished version of your assembler finished, it sounds 
like it would be a great tool.

Andy

Andrew Greensted wrote:
> Sylvain Munaut <SomeOne@SomeDomain.com> wrote:
>> Hi,
>>
>> I wasn't very satisfied with the available assembler, so a few month
>> ago I wrote a new compiler for the Picobaze during my spare
>> weekends ...
> 
> Hi Sylvain,
> 
> Nothing to add but encouragement really. The software offerings for 
> picoblaze are limited, especially in the non-windows world. Both picoasm 
> and kpicosim are very good, but their development seems to have stopped.
> 
> If you can get a polished version of your assembler finished, it sounds 
> like it would be a great tool.
> 
> Andy

Of course, you're working on the simulator now, right?  :)

Sylvain Munaut wrote:

> Hi,
> 
> I wasn't very satisfied with the available assembler, so a few month
> ago I wrote a new compiler for the Picobaze during my spare
> weekends ...

I think you mean a New Assembler ?

> 
> I just though I'd share it if anyone is interested ....
> 
> It's available there :
>   http://www.246tnt.com/files/PBAsm_20080225.tar.bz2
> 
> Example usage:
>  python ./Codegen.py example.S out.mem
> 
> WARNING: The last file on the command line is the output ... so if you
> forget it, it will overwrite your last source file ...
> 
> What are the pro and cons:
> 
> pros:
>  - Cross platform
>  - It supports local label, so for labels that don't really deserve a
> name you can do things like
> 
>     load s0, 15
> 1:
>     sub s0, 1
>     jump nz, 1b
> 
>    And the '1b' reference says to find the first label named 1 when
> going 'back' (1f would be forward...).
>    Local labels are just a single digit.

Hmmm - could be dangerous for maintenance. Another scheme is to use '?' 
or similar prefix to mean local label.

> About the hw mods to the hw :
>  - I removed the ScratchPad distributed RAM and used the second port
> on the BRAM as scratch pad. The second port is configured as 8 bit
> width and with upper address lines mapped to 1 so that the SP is
> located at the end of the BRAM. (Be careful when playing with this and
> interruptions, the last 2 bytes of the scratch pad is the interrupt
> vector ...) And the bonus is a 256 byte scratch pad, just sacrificing
> 128 instruction words ... (adjust mapping for other tradeoffs)


Have you looked at the Lattice Mico8 - Quite similar to the Picoblaze,
but more formally opensource, and they have just extended it to make it
more 'HLL ready'.

Have a look and see if your opcode extensions can fit into their
decode ?

-jg

> > I wasn't very satisfied with the available assembler, so a few month
> > ago I wrote a new compiler for the Picobaze during my spare
> > weekends ...
>
> I think you mean a New Assembler ?

Yes :) I was careful in the subject but that one slipped.


> >  - It supports local label, so for labels that don't really deserve a
> > name you can do things like
>
> >     load s0, 15
> > 1:
> >     sub s0, 1
> >     jump nz, 1b
>
> >    And the '1b' reference says to find the first label named 1 when
> > going 'back' (1f would be forward...).
> >    Local labels are just a single digit.
>
> Hmmm - could be dangerous for maintenance. Another scheme is to use '?'
> or similar prefix to mean local label.

I've used the same convention as the GNU assembler. I've modelled the
syntax
after theirs, but making sure it's easy to parse with Lex / YACC. As
it was my
first lex/yacc experience I didn't want to take too much time to make
it work.

Especially since I needed that compiler to ease my work for a
commercial project with an approaching dead line :)


> Have you looked at the Lattice Mico8 - Quite similar to the Picoblaze,
> but more formally opensource, and they have just extended it to make it
> more 'HLL ready'.
>
> Have a look and see if your opcode extensions can fit into their
> decode ?

I had a look at the Lattrice Mico8. But since my target was Xilinx,
the picoblaze seemed like a better choice (smaller and faster ...)
I didn't investigate further and just coded this assembler to have an
easier time when programming it.

I'm not that interested in HLL because when I uses theses. But a macro
preprocessor would be nice :)

Sylvain

> Of course, you're working on the simulator now, right?  :)

I don't think so ... I rarely used the one that are available because
the code on the picoblaze is often so dependent on the hw around it
that it just doesn't do anything meaning full without it ...

What I did is that my assembler output a symbol table and so in the
modelsim you can get it to display :

uart_print_str + 0x00, uart_print_str + 0x01 .... instead of the
addesses in the code, and also the variable name instead of address in
the scratch pad. Very useful to trace what's going on.


    Sylvain

On Feb 26, 9:47 am, Andrew Greensted <ajg...@ohm.york.ac.uk> wrote:
> Sylvain Munaut <Some...@SomeDomain.com> wrote:
> > Hi,
>
> > I wasn't very satisfied with the available assembler, so a few month
> > ago I wrote a new compiler for the Picobaze during my spare
> > weekends ...
>
> Hi Sylvain,
>
> Nothing to add but encouragement really. The software offerings for
> picoblaze are limited, especially in the non-windows world. Both picoasm
> and kpicosim are very good, but their development seems to have stopped.

Yes they did a great job and I used those for a some time.
But since they respected the Xilinx 'standard' assembly format, they
were limited ...

I choose to break compatibility so that I could extend easily. But
even without the compatibility, it's pretty easy to convert old
software.
Mostly a few subsitute with regexp and adding a .text at the start and
that should do it :)


> If you can get a polished version of your assembler finished, it sounds
> like it would be a great tool.

Thanks.

I'll try to polish things up a little and maybe write some
documentation and so forth.

But I probably won't do a lot of work on it since I changed job and
this new one is not related to fpga (nor hw dev) in any way ...

Sylvain

"Sylvain Munaut <SomeOne@SomeDomain.com>" <246tnt@gmail.com> wrote:
>
>I'm not that interested in HLL because when I uses theses. But a macro
>preprocessor would be nice :)

You can use plain old cpp for that purpose. A few months ago I wrote a
PLC compiler thingy. I used cpp as a preprocessor for it.

-- 
Programmeren in Almere?
E-mail naar nico@nctdevpuntnl (punt=.)

On Feb 27, 9:15 pm, n...@puntnl.niks (Nico Coesel) wrote:
> "Sylvain Munaut <Some...@SomeDomain.com>" <246...@gmail.com> wrote:
>
>
>
> >I'm not that interested in HLL because when I uses theses. But a macro
> >preprocessor would be nice :)
>
> You can use plain old cpp for that purpose. A few months ago I wrote a
> PLC compiler thingy. I used cpp as a preprocessor for it.

Mmm, I hadn't tought of that.
That's a nice easy way to get a well known syntax.

However for an assembler it's nice to have more 'advanced' things. I'm
not an expert in the C preprocessor but making a macro that would
expand :

STACK_PUSH(s0, s1, s2, s3)

into

store s0, (sp)0
store s1, (sp)1
store s2, (sp)2
store s3, (sp)3
add sp, 4

Seems kinda hard ...

Sylvain