<GitHub61>
[migen/master] corelogic/ReorderBuffer: do not touch empty count when issuing and reading at the same time - Sebastien Bourdeauducq
hypermodern has joined #milkymist
<lekernel>
stekern: thanks for the patch:
<mwalle>
wpwrak: btw is there another argument than saving the extra save on exception for putting the control bits into IE?
<mwalle>
after some thinking, putting ITLB/DTLB/USR flag into an own register seems less hackish to me
<mwalle>
you retain full backwards compatibilty and you have a clear separation between nomuu and mmu
antgreen` has quit [Remote host closed the connection]
antgreen` has joined #milkymist
<azonenberg>
wolfspraul: FYI
<azonenberg>
my 2-layer LX9 breakouts shipped from the fab
<azonenberg>
should be at my place early next week
<mwalle>
azonenberg: do you solder bgas yourself?
<wpwrak>
mwalle: i'm not sure which of the two approaches is better. merge them and you have to worry about keeping them apart in cases where you don't want to touch the MMU. keep them separate and you need an extra set of save/restore operations.
<azonenberg>
mwalle: this board is a TQFP144 XC6SLX9 on 2 layers
<azonenberg>
i have done FTG256 bga on 4 layers by hand, though
<mwalle>
azonenberg: with an ir heater?
<azonenberg>
toaster oven
<lekernel>
wpwrak: the latter is just 2 instructions, no?
<mwalle>
wpwrak: mh, otoh renaming IE to PSW and have an IE bit at the same position, sound good to me, too.. mhmhmh ;)
<lekernel>
context switching is already rather slow on lm32 with all the registers to save manually
<mwalle>
azonenberg: nice
<mwalle>
azonenberg: did it work in the first place?
<lekernel>
so it wouldn't make a big relative difference imo
<azonenberg>
lekernel: hardware multithreading :D
<lekernel>
what about keeping the current "backward compatible" IE register, and adding an IE+MMU register?
<lekernel>
(duplicate the IE bits)
<lekernel>
not sure if this makes any sense though... the extra MMU bits shouldn't bother you for backward compatibility, unless you want to run software which is broken in the first place
<lekernel>
mwalle: PSW = processor status word? :=
<wpwrak>
lekernel: TLB reloading should be a very short path. nothing like a full context switch.
<lekernel>
mwalle: no, why?
<lekernel>
ah, yes, heard of him
<wpwrak>
lekernel: having a "new IE" register would be an interesting option, yes
<lekernel>
just didn't remember his name...
<mwalle>
lekernel: because he lives in berlin and visited the cbase i guess
<lekernel>
tbh I rarely go to c-base... little gets done here, except drugs, porn (only watching unfortunately), alcohol, video games, youtube, etc.
<mwalle>
mh ok ;)
<lekernel>
he's coming a little late, berlinbiennale.de is just over and it was an interesting place for such funny ideas
<mwalle>
Fallenou: what is I/DTLBMA?
sh4rm4 has joined #milkymist
<stekern>
lekernel: np, I'll try to put together the byval patch during the weekend. I've almost nailed it, just a minor problem with fp an ra ending up in the same stack slots as the byval aggregates, but I know what I need to do to fix that.
antgreen` has quit [Remote host closed the connection]
mumptai has quit [Quit: Verlassend]
hypermodern has quit [Remote host closed the connection]
<GitHub78>
[llvm-lm32] jpbonn pushed 1 new commit to master: http://git.io/0nJmNg
<GitHub78>
[llvm-lm32/master] Since LM32FrameLowering::hasReservedCallFrame() always - JP Bonn
<mwalle>
lekernel: wpwrak: what do we do with the non-cacheable memory, eg atm 0x0000-0x7fff is shadowed at 0x8000-0xffff with the latter being uncached
<mwalle>
i guess this just works fine with the mmu, eg. i can set the physical address to 0x90000000 to access 0x10000000 uncached?
<wpwrak>
hmm, sacrificing half of the address space seems a bit expensive
<wpwrak>
but i guess it's okay for getting started
<wpwrak>
if this bypasses the cache, perhaps it should also bypass the TLB, and be allowed only in supervisor mode
<mwalle>
wpwrak: imho 2gb is more than enough
<mwalle>
wpwrak: but then only the kernel could access the hw uncached
<roh>
so what.
<roh>
drivers belong into kernelspace anyhow
<mwalle>
roh: the hw should not enforce restrictions onto an os..
<roh>
sometimes i think thats the lesser evil compared to the pain of living with the result elsewise
<wpwrak>
user-space drivers are not necessarily evil :)
<roh>
exactly. the world is a better place without em.
<wpwrak>
depends ... some are nasty most are not
<mwalle>
wpwrak: do you think it should be possible to read back the TLB entries from the HW?