#timvideos

CarlFK: yes, we should see the boot squence printk messages, they are written to the main console

cr1901_modern: great, if you have any gcc questions let me know

shorne: sounds like a simple fix ;)

jk- I can't imagine anything VM being simple

shorne: Actually I do unfortunately. But not for or1k, but rather for lm32

are you still willing to help?

cr1901_modern: sure, the guys one OFTC/#gcc are very helpful for gcc questions too

please let me know

shorne: I have an example ready right now

ok

shorne: http://ix.io/1nH0

In this code, gcc decides the best way to get to the value of .LC0 is to load .LC1 and then do a load-word.

Why would code like this be generated instead of directly loading the value of .LC0?

cr1901_modern: looking, what optimization level are you using -O0?

I see

-O3

shorne: Context if you're interested: https://twitter.com/cr1901/status/1045419756763...

We've been talking about constant pools and constant generation all day in #j-core, trying to beat it into my head

I see, its a bit strange let me just try with my compiler

cr1901_modern: https://gist.github.com/16222a6b989e040962b2414...

Title: put.s · GitHub (at gist.github.com)

no issue there

right or1k does the right thing

(yay a delay slot actually used for once)

cr1901_modern: yes, it generates better code than I could do (most of the time :))

there are a few optimizations left to do... but want to get upstream first

let me look at the lm32 port

it might be something with how the mov* pattern is implemented

but its also just strange that it defines the .LC1 reference in the first place

shorne: Tyvm, this makes me feel a lot better

cr1901_modern: notice strings are in '.rodata.str*' section the pointers are in '.rodata.cst*'

shorne: I did _not_ notice this :).

I have no idea what this means, but it indicates it's a deliberate decision

Yeah, also I see lm32 defines this small data thing...

Title: gcc/lm32.c at or1k-port · stffrdhrn/gcc · GitHub (at github.com)

I am not quite sure, but it might mean it stores data and var references in seprate sections?

.rodata.cst - is for constants

cr1901_modern: I looked through the lm32 port, those are the things that stood out. There might be a reason for it, but I cant see why right now.

shorne: Sorry for the delay, thanks for taking a look

Maybe I'll contact lattice

checking in the #gcc room on the OFTC server doesnt hurt

or just sending gcc an email

or raise a bug

shorne: I think I will do that, or at least stop in. Unfortunately tonight I'm really getting my ass kicked in #j-core re: constants and PIC and crap

CarlFK: one thing

build/arty_net_or1k.linux/software/include/generated/csr.h:#define CSR_UART_BASE 0xe0001800

third_party/linux/include/dt-bindings/litex.h:#define CSR_UART_BASE 0xe0001000

there is a sifference in the location of UAT between linux and qemu

UART* that would be the first problem

Lets see what else

Ill also check if maybe devicetree generation woths

works*

mithro: Hi tim, I see during ./script/build-linux.sh you check out litex-devicetree, but I dont see it being used

I tried to use it an it seems to have some bugs

any comment on the current state of it?

I will try to manually update the or1klitex.dts for the moment

shorne: There is one more q I have re: gcc, but doesn't need to be tonight. Does or1k use constant pools AND have a mvhi/mvlo idiom?

shorne: I expect mithro is asleep right now - 3am ish

CarlFK: we dont use constant pools, we have a GOT when specifying fPIC which is kind of similar

I don't see how a GOT is similar to a constant pool, but my mind is kinda friend tonight

we have the same mvhi/mvlo, we do 'l.movhi r2, hi(symbol)' 'l.ori r2, r2, lo(symbol)' or 'l.addi ...'

cr1901_modern: well, before right now I never really heard of a constant pool, I read this http://benno.id.au/blog/2009/01/02/literal-pools

Title: The trouble with literal pools (at benno.id.au)

it says literal pool, maybe completely different

it's using pc-relative addressing to access a constant value stored in the binary. It uses one less insn than mvi/mvlo

yeah

Ultimately, they both require the same amount of bytes tho; constant pools just move one of those 32-bit words to the data cache

what I was confused about is MIPS seems to use both mvhi/mvlo idiom and a constant pool to generate constants: sorear: GOT is needed *for code in shared libraries* because it's the only way to make interposition work

err sorry, ignore that, paste fail

Title: gcc/mips.c at master · gcc-mirror/gcc · GitHub (at github.com)

Naturally I don't understand it, maybe someone who works on GCC has a better idea on how the MIPS backend decides which constant generation scheme to use

cr1901_modern: it seems gcc likes to use constant/linteral pools by default

I see in openrisc we set this

Title: gcc/or1k.c at or1k-port · stffrdhrn/gcc · GitHub (at github.com)

(the comment says don't allow to use literal pool)

Just heading to the airport to go back to the US

CarlFK: spent some time tracing the kernel boot, it seems to not be running, it has failed during boot. What I thought was running was just a delay loop, not idle loop

shorne: Have you tried attaching a debugger?

...using qemu

xobs: yes, and I can trace it

but.. I cant read memory for some reason I get

.. Cannot access memory at address 0xc0452930

but maybe thats because everyting has crashed let me try to put a breakpoint before it crashes

no... I can set breakpoints but still cant read memory

something wrong with qemu/gdb

hmm, It looks like I can read memory when mmu is disabled