<gordonDrogon>
I was paid to port Suns OBP to new Sparc hardware at one point - well, it was part of a salaried job, however I was the one who didn't step back fast enough at the time!
<gordonDrogon>
I also tried to enjoy Forth on the apple II before then too - I had a FIG Forth and Graforth - the Graforth was good as I could do 3d wireframe graphics stuff much faster than anything else (and easier than writing assembler!)
<gordonDrogon>
there is also a relatively new facebook group called minimalist computing - it seems to encourage Forth types to it too... It does have a fairly loyal following - but maybe that's true of other things - like me & BCPL .. although I suspect that's a fanbase of just one now ...
joev has joined #riscv
kehvo has quit [Ping timeout: 240 seconds]
seninha has quit [Quit: Leaving]
jacklsw has joined #riscv
ivii has joined #riscv
ivii has quit [Remote host closed the connection]
Andre_H has joined #riscv
aburgess has quit [Ping timeout: 256 seconds]
prabhakarlad has quit [Quit: Client closed]
Andre_H has quit [Quit: Leaving.]
seninha_ has joined #riscv
seninha_ has quit [Remote host closed the connection]
<muurkha>
hahaha
<muurkha>
yeah, I want to love Forth but so far I haven't gotten to the point where it's my tool of choice for ... anything
<muurkha>
ideologically it seems like it would be awesome, so maybe I just don't have enough experience with it
<muurkha>
but untyped pointers to memory just seem like a pain compared to OCaml or Python or Golang or even C
<muurkha>
and I never got to the point where my code was *readable*
mahmutov has joined #riscv
jacklsw has quit [Quit: Back to the real life]
aburgess has joined #riscv
mahmutov has quit [Ping timeout: 252 seconds]
mahmutov has joined #riscv
huseyinkozan has joined #riscv
<gordonDrogon>
untyped pointers? Well.. BCPL has that :)
mahmutov_ has joined #riscv
mahmutov has quit [Ping timeout: 252 seconds]
<muurkha>
it sure does!
<muurkha>
interestingly I find assembly language less of a pain than Forth, even though it's (generally speaking) just as untyped
<muurkha>
it's more laborious though and it takes more time to get things done
<gordonDrogon>
If people view C as a glorified assembler, I wonder what they think of BCPL...
BOKALDO has quit [Quit: Leaving]
<gordonDrogon>
muurkha, did I show this> I did another simple annotated view of a simple BCPL program - someone was saying that the C compiler on the esp2866 was outputting dozens of lines of asm per line of C ...
jjido has quit [Quit: My MacBook Air has gone to sleep. ZZZzzz…]
aburgess has joined #riscv
sobkas has joined #riscv
sobkas has quit [Client Quit]
<muurkha>
yeah!
jmdaemon has joined #riscv
sobkas has joined #riscv
JanC has quit [Remote host closed the connection]
JanC has joined #riscv
sobkas has quit [Ping timeout: 272 seconds]
sobkas has joined #riscv
___nick___ has quit [Ping timeout: 252 seconds]
sobkas has quit [Ping timeout: 240 seconds]
mthall_ has quit [Ping timeout: 240 seconds]
mthall has joined #riscv
wingsorc has joined #riscv
mthall has quit [Ping timeout: 272 seconds]
mahmutov has quit [Ping timeout: 252 seconds]
mthall has joined #riscv
<gordonDrogon>
muurkha, I added some more to that z.b.txt above to put in the RISC-V codes for each instruction.
<muurkha>
nice!
<muurkha>
K4G is a bit lengthy
<gordonDrogon>
what you don't see if this: https://unicorn.drogon.net/nextOpcode.txt in-lined after every bytecode instruction. in a lot of cases the overhead of the fetch/jump is a lot more than the operation itself.
<gordonDrogon>
Yes - the calls are quite involved, but in essence - increase the stack, store return PC and old SP and first argument on the stack.
<muurkha>
yeah
<muurkha>
you could probably compile each instruction to a call to millicode
<gordonDrogon>
that call has to fetch the address from the global vector - a table of addresses - it's a crude way if linking into the shared librarys.
Andre_H has joined #riscv
<gordonDrogon>
it might actually make sense to do a post process to do just that. it would fly even more.
<gordonDrogon>
although the resulting binary would be much larger - 4x if not more, but hey, ram is cheap ...
<muurkha>
just 4x I think?
<gordonDrogon>
a simple one-byte opcode becomes at least 4.
<muurkha>
I think ram is expensive
<gordonDrogon>
and K3G is 2 bytes, that becomes 36 bytes
<muurkha>
hmm, can't you compile K3G into a millicode call? I guess you need some way to pass it the address of the non-millicode routine to call
<gordonDrogon>
what's a millicode call?
<muurkha>
a call to a "millicode routine". like microcode, but it's just regular code
<gordonDrogon>
oh, to sace space overall? I could, but I want speed - the whole system runs with lots of inline code - there are no subroutine calls at all.
<muurkha>
yeah, but I suspect this would probably be faster than inline NEXT
<gordonDrogon>
yes - once I get real hardware I might have a look at that.
<muurkha>
the idea is that you compile sequences like L1; AP3; SP3; L9 into call L1; call AP3; call SP3; call L9
<gordonDrogon>
although I could do it in my emulator here but going to be very busy in the next 2 weeks (funeral which involves 2 days travel, then a swim teach training course)
<muurkha>
so instead of executing lbu; slli; add; inc; lw; jalr to go to the next bytecode, you'd just execute a return and call
<gordonDrogon>
that would vertianly save a lot of space
<muurkha>
there's a particular register the RISC-V ABI sets aside as a link register for millicode
<muurkha>
x5
<gordonDrogon>
ok. weird. the term 'millicode' is new to me though!
<muurkha>
it was new to me too! but apparently it goes back a while
<gordonDrogon>
1997 apparently.
<muurkha>
I think the idea is that millicode routines can be invoked by compilers pretty much as easily as normal instructions. not sure how you're supposed to give them arguments, though. a preceding LUI?
<muurkha>
LUI seems inconvenient
<gordonDrogon>
especially for the L? opcodes here - it's 2 RV instructions, so the call needs to be just one instruction.
mthall has quit [Ping timeout: 240 seconds]
<gordonDrogon>
so what I need is a fusion that starts mv regB,regA ;-)
<gordonDrogon>
every register load operation starts with that...
<muurkha>
well, you could very reasonably have separate millicode routines for L1, L2, etc.
<gordonDrogon>
overhead of CALL/RET is the same as the 2 RV instructions for each one though...
<gordonDrogon>
might be more if there is a cache involved...
<muurkha>
true!
<muurkha>
maybe more if superscalar too
<gordonDrogon>
so ther may well be good points, but also bad ones - hard to tell without some sort of experimentation and likely different for different implementations. who knows..
<gordonDrogon>
but it'll have to wait as I have a big drive tomorrow and it's bed time :)
Andre_H has quit [Quit: Leaving.]
huseyinkozan has quit [Quit: Konversation terminated!]