Hello,
That is really interesting, thank you for providing that.
I see that su.b contains non-ascii characters ($11,$12,$13,$14) which
tripped my linux console when I attempted a copy paste, since $13 is
XOFF :) Is there a way to escape these characters? Or update them, since
it looks like a password provided on command line.
In its current state my compiler managed to eat all these sources except
goto which segfaults for a reason I have not determined yet.
May I have your authorization for copying these files into my own b
compiler repository (
https://git.sr.ht/~f4grx/bpars )? What licence and
attribution info shall I indicate?
Sebastien
PS: here is the 68hc11 assembly that the current version of my B
compiler generates for echo.b. Code is still not functional, parameters
and locals are not allocated, but instructions are consistent.
this mcu is similar to 6502 and other cpus in the motorola 6800 line:
two 8-bit accumulators A,B combinable into D, and two 16-bit index reg X
and Y (Y is not used), 16-bit SP.
/*---------------------------------------------------------------------------*/
.text
.global main
.func main
main:
#function has no args
#local var i size 2 stack offset 0 TODO
#total stack frame size for compound: 2
LDD #1
STD i /*Direct assign - local*/
.Lwhile_1:
/*binop, both complex*/
/*generate RHS in D, then move in temp*/
in gen_index: computing base expression (as lvalue)
in gen_index: lvalue=1
LDX #argv /*lvalue-extern*/
in gen_index: computing base expression done
LDD 0,X
PSHB
PSHA
/*generate LHS in D*/
LDX #i /*lvalue-local*/
LDD 0,X /*Get value in X for easy 16-bit op*/
XGDX /*Now value is in X and address in D*/
INX /*Do the preinc*/
XGDX /*Now updated value is in D and address in X*/
STD 0,X /*Save the new value, next code can use it*/
/*execute*/
PULX /*--- Recall complex B computed before */
STX TEMP /*---put in temp for binop*/
CPD TEMP
BGT .Lcond2
#start emit arglist for call
.section .rodata
.strconst_3:
.asciz "%s "
.text
LDD #.strconst_3
PSHB /*argoff=0*/
PSHA
in gen_index: computing base expression (as lvalue)
in gen_index: lvalue=1
LDX #argv /*lvalue-extern*/
in gen_index: computing base expression done
LDD i /*local*/
LSLD
STX TEMP
ADDD TEMP
XGDX
LDD 0,X
PSHB /*argoff=2*/
PSHA
#end emit arglist, size=4
JSR printf /*undef*/
PULX
PULX
/*end of loop, eval condition again*/
BRA .Lwhile_1
.Lcond_2:
#start emit arglist for call
LDD #10
PSHB /*argoff=0*/
PSHA
#end emit arglist, size=2
JSR putchar /*undef*/
PULX
.Lstmtend_0: /*TODO avoid generating this if the statement does not
contain breaks (no need for recursion)*/
.Lmain__rts: /* TODO avoid this label if statement contains no return */
RTS
.endfunc # main
Le 14/06/2023 à 22:03, Angelo Papenhoff a écrit :
After writing this mail I actually started reversing
the B binaries.
You can find them here:
http://squoze.net/B/programs/
I did find some differences in versions of the B runtime and library.
Especially interesting was an implementation of the cksto routine
in su and stty that checks whether an address in an assignment is in a
reasonable range ("LV out of range" error if not)
What is perhaps interesting historically is that the su binary contains
a hardcoded password ^Q^R^S^T, which is not printable for a good reason:
it is given as a command line argument.
I will hopefully continue with this in the next time (if, goto, mail and
glob are left).
Best,
aap
On 14/06/23, Angelo Papenhoff wrote:
> Thank you two for finding this!
> I did some disassembling yesterday and have uploaded brt1.s and brt2.s
> to my site now:
http://squoze.net/B/brt/ (I haven't actually assembled
> them yet, there may be mistakes)
>
> Some observations:
>
> - The 'chain' format is actually a linked list and not a list of
> addresses. Phil and I both got this wrong.
>
> - The "Init" string is an error message if for some reason the B init
> chain didn't run or main doesn't look like a function
>
> - The cmdline arguments overwrite part of the init code. There's about
> 80 bytes of space for them before it overwrites the code that builds the
> argv vector
>
> - brt2.s is only to mark the beginning of the stack
>
>
> I also saw some differences in the bilib code but haven't really
> analyzed that part (yet?)
>
> Would be really great if we could get all the files disassembled and
> decompiled and restore the source code for everything :)
>
> Best,
> Angelo