* tabemann
is working on the disassembler to make its output more gas-friendly when used in for-gas mode
<rdrop-exit>
cool
<rdrop-exit>
never cared for gas personally
<tabemann>
well this is mostly so the user can have assembler-friendly code that they can feed into an assembler
<tabemann>
by "gas" I mean the standard ARM assembly syntax
<tabemann>
note that there's also a (default) user-friendly mode that generates assembly that would be, well, user-friendly
iyzsong has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
<rdrop-exit>
your assembler isn't RPN?
<rdrop-exit>
your gas mode is so that they can cut and paste into an external assembler?
<rdrop-exit>
cool
TCZ has joined #forth
<tabemann>
back
<rdrop-exit>
wb
<tabemann>
I don't have a built-in assembler; rather my disassembler syntax is based off of ARM syntax, with some modifications
<tabemann>
the "gas" mode eliminates those modifications and makes it entirely standard
<tabemann>
e.g. it eliminates addresses and raw instruction data for each instruction
<tabemann>
and in some places where I treat a PC-relative address like it were absolute instead I explicitly treat as PC-relative
<rdrop-exit>
I see
<tabemann>
it also modifies label names so they're assembler_friendly
<tabemann>
like it turns */ into star_slash
<tabemann>
another thing is that "gas" mode never truncates label names, whereas in non-"gas" mode labels over 20 characters for individual lines are truncated to 20 characters
<rdrop-exit>
I usually don't worry about external assemblers
<tabemann>
well the kernel of zeptoforth is written in gas assembly
<rdrop-exit>
at some point you'll probably want to give zeptoforth its own assembler
<tabemann>
I wonder how large such an assembler would be
<tabemann>
the disassembler for zeptoforth is 20K, but that's because I aggressively optimized it and excluded instructions not used by zeptoforth
<tp>
hi all!
<tabemann>
hey tp!
<rdrop-exit>
hi tp!
<rdrop-exit>
depends on how regular the target's ISA is
<tp>
tabemann, I like your work with the gas friendly output, Zeptoforth is becoming interesting to me
<tabemann>
Thumb-2 is awfully big for something meant to be small
<tp>
tabemann, I'm still working on the bit@ page, it's my current project
<tabemann>
tp: I'm doing more work on the gas friendly output
<tp>
tabemann, awesome
<tabemann>
namely I've made it so that */ is converted to star_slash
<tabemann>
and assembler-main is converted to assembler_main
<tp>
tabemann I like your explicit PC-relative treatment, youre reading my mind!
<tp>
hey rdrop-exit, how goes the local lockdown ?
<tabemann>
the only part I wonder about whether I should have it is adding labels inside words like 1:, 2:, 3:, etc.
<rdrop-exit>
good, extended again I think
<tabemann>
the problem is that would make it substantially more complex
<tp>
tabemann, I like those relative labels from my previous gas work
<tp>
tabemann, I mean it's nice to be able to create some binary from Forth that will compile in gas for the odd test or usage
<tp>
tabemann, I'll either have to patch Mecrisp-Stellaris to generate gas friendly output or transform it with xml I guess
<tp>
tabemann, I've been doing the mods by hand and then feeding into apps like RA2 etc
<tabemann>
now that I think about it, I think I know how I'd implement relative labels
<rdrop-exit>
does Mecrisp-Stellaris have an assembler?
<tp>
rdrop-exit, sure
<tabemann>
I've got a question: how many labels do you think I should support per disassembly?
<tp>
tabemann, excellent question, I dont have an answer
<tabemann>
I think 64 would probably be sufficient
<tp>
tabemann, I think it would!
<rdrop-exit>
tp, does it use gas syntax or RPN?
<tp>
rdrop-exit, neither
<rdrop-exit>
ok, thanks
<tp>
rdrop-exit, it's similar to GAS but not 100% compatible
<rdrop-exit>
I see
<tp>
tabemann, my aim so far has been to use Forth to write test code which I then test on the mcu, then dissasemble and check out, and finally plug into the Mecrisp-Stellaris kernel itself
<tp>
tabemann, thats a easy way when porting to another model and altering the terminal.s and so on
<tp>
unlike the usual gas assembly where if *anything* is wrong, one gets nada by way of feedback
<tabemann>
that's definitely nicer than just writing straight assembly
* tabemann
is working on 1: / 2: / 3: / etc. labels right now
<tp>
tabemann, absolutely, and if you have that mechanism in place users may find porting that much easier, which will mean less emails pleading for your time to do really simple stuff