02-10-2015, 05:31 PM
02-11-2015, 06:26 PM
(02-11-2015, 03:55 PM)DJ8X Wrote: It would be nice to have native ./autoprogram support The only problem is that everyone (as you can see from this thread) has different ROM configurations so adding native support would mean a different section of code for everyone's CPU. I'd be willing to help out anyone who was going to make a parser but adding it into the script would be impractical.
02-12-2015, 05:57 AM
(This post was last modified: 02-12-2015, 05:59 AM by LordDecapo.)
It would be easier just to make a filter program to turn the binary assembly into autoprogram
hell, have the program prompt for the variables it needs to generate the autoprogram, then have it just do a final pass to convert it the last bit. But I would still want the plane binary output as well
02-12-2015, 06:46 AM
I'd rather just focus on getting the assembler itself going with as much functionality as possible before adding another stage. At the moment I'm looking for the ability to split variables across the instruction (e.g. if you had your op code in two halves at either end of your bit layout or something). Also I want to add the ability to place the instruction keyword anywhere in the line rather than always at the start. I'd like to actually have a chat with a few people about what features they would find important for their instruction set and also the actual layout of the .yaml file. There is a lot that can be improved on and a lot will change over time. For now, it should work for simply laid out ISs but I don't want that to be the only case it will work in.
Could I also suggest supporting optional arguments in an instruction?
For example, I have an instruction where 1 bit decides wether or not to invert a register value. At the moment I can have an argument to specify wether or not to invert, but It's kinda awkward how I have to say when I DON'T want it inverted too. e.g. I'd like to be able to define an instruction that could take such combinations: ld r1 r2 ld r1 ! r2 ld r1 r2 ! ld r1 ! r2 ! Another suggestion would be to allow the counting of address lines and a little bit of macro, so you could do this: ld r1 r2 #loopstart add r1 jmp $loopstart
02-12-2015, 12:39 PM
Address line counting as mentioned by mag... would be amazing
02-12-2015, 05:11 PM
(02-12-2015, 11:16 AM)The Magical Gentleman Wrote: ld r1 r2 you could make custom arguments for something line '!r1' instead of having a separate thing then use a var and have one possibility being a normal register (like 'r1') and that puts a 0 in the signifier bit and the reg value in the next bits and the other possibility being the custom argument with a 1 in the signifier bit and then the value you assigned in your definition. I agree it's a bit of an ugly solution but it's the best I've got at the moment As for the addressing and referencing, I love that. It's definitely top of the TODO list.
02-23-2015, 12:51 AM
*UPDATE* See original post
02-23-2015, 03:54 PM
Hi Jallen,
If I understand: I write an IS.yaml file, provide an input file (a program in my custom assembly-language), and the python program will output the assembled machine code. A custom assembler would be a very handy tool to have. This is a nice service to the community, props to you. I have a question/feature request: Can the tool include line numbers, and the assembly instructions in its output? With this, the output would be in 3 columns, and might look something like... 00 # 00101101 # LDX $01,$11 01 # 00111000 # LDY $00,$10 .... and so on.... <excuse the bad formatting, I can't work html> <arbitrary spacing/separator, hopefully you get the idea> Cheers, |
|