ZombieChicken has quit [Remote host closed the connection]
<OmniMancer>
:O
<GenTooMan>
you can allocate random blocks of memory and then delete and reallocate them?
<tpw_rules>
no, register allocator
<tpw_rules>
it uses Graphs
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
<GenTooMan>
local variable allocation then?
<tpw_rules>
yeah
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
<GenTooMan>
that's fun to do. It's definitely not as simple as the "use the stack" idea. It is however much faster. I've seen several compilers do it wrong and ... well let's just say bad optimization is possibly worse than no optimization.
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
<GenTooMan>
Oh yeah congrats on your success. :D
ZombieChicken has quit [Remote host closed the connection]
<tpw_rules>
it's for wq's boneless so i don't have to think about registers anymore
<tpw_rules>
i really agree with her vision that a good assembler should have an allocator too
<tpw_rules>
it's still missing some features, like being able to spill anything and to understand the calling convention
<tpw_rules>
but it works, very surprisingly
<tpw_rules>
(and once again reinforced my belief that papers and "the literature" are kinda useless)
<GenTooMan>
It's always good to see what people are thinking. Unfortunately papers have become like sports. They compete using their mind as the game tool instead of their hands and feet. However the result seems mostly the same, unproductive use of time.
<tpw_rules>
if i wanted to say it positively, i would say that actually implementing something is the highest form of understanding
<tpw_rules>
but it's frustrating coming across like 10 papers and class slideshows that all miss the same bit
<GenTooMan>
that bit you need to complete your task at hand?
<tpw_rules>
yeah. and it always turns out that they've elided something or that you need to just do it slightly differently for your application
<tpw_rules>
anyway other positive is that my allocator is already better than me. i ran through a real life routine with 75 instructions. i allocated 7 registers, it did it in 6
ZombieChicken has joined ##openfpga
<GenTooMan>
and you tested the code I assume as well?
<GenTooMan>
now their is just boneless C ... and we are good to go ... LOL
<tpw_rules>
yeah
<tpw_rules>
eh, C is lame
<tpw_rules>
with bones or not
<OmniMancer>
boneless Rust :P
<tpw_rules>
i feel like asm with a register allocator and an expression engine is gonna be boneless C
<GenTooMan>
sort of like PDP11 assembler. You could easily write entire applications in that. It was very weird to do so also. Felt rather retro doing that.
<OK_b00m3r>
GenTooMan: asm was an applications languge for a remarkably long time. into the 1990s at least.
<OK_b00m3r>
probably still hangs on.
<tpw_rules>
there's still weirdos that use it as such
<GenTooMan>
I wrote ASM translators for several processors. It was weird but it was faster than rewriting 81 programs.
<GenTooMan>
each has it's uses. I use assembly when the compiler generates crap code, or intrinsics either way. Hey let's all think in reverse polish notation!
<OK_b00m3r>
any minute now someone will mention the spineless
<OK_b00m3r>
g machine
<cr1901_modern>
Boneless p-code interpreter
<tpw_rules>
only time i've used assembly on a pc in recent memory is i did a couple image scaling routines in ARM NEON
<tpw_rules>
i wonder why it ended up like that. was it patents like the nes?
<OmniMancer>
who knows, the lack of in and out make sense
<OmniMancer>
since it doesn't separate IO bus and memory bus
<OmniMancer>
being embedded in a larger chip
<GenTooMan>
Well in Japan their is a city named USA for similar reasons.
<GenTooMan>
it's possible they were skirting copywrite laws.
<tpw_rules>
there's exactly one transistor missing out of the 6502 in the nes to avoid a patent, but the gameboy cpu is a serious revamp
<tpw_rules>
comparatively
<GenTooMan>
Japan is never afraid of doing something wildly different at least.
<GenTooMan>
likely having a semi custom IS was advantageous to them.
<OmniMancer>
The gameboy ons is a Sharp part apparently
<OmniMancer>
oh hey attosoc takes exactly 50% of the LUTs that I have exposed in the generic backend :P
<OmniMancer>
not quite
<OmniMancer>
4906/9800
OmniMancer has quit [Quit: Leaving.]
<GenTooMan>
you keep reminding me of things I should do OmniMancer.. stop it LOL
<tpw_rules>
huh he left
<tpw_rules>
anyway uh i think the gameboy cpu is just manufactured by sharp. the die has all the video and sound stuff on it too
<tpw_rules>
ricoh made the cpu and ppu for the nes and snes but i don't think they were especially involved in designing them
<GenTooMan>
Well considering Japan highly complex culture ... it's not a surprise at all.
<cr1901_modern>
I don't have a link handy, but the CPU for the SNES was IP purchased from WDC- i.e. no difference from the 65816 ICs that WDC was putting out in the late 80s.
<tpw_rules>
yeah the actual core was (and so was almost the NES's) but it's still on a nintendo custom die with the controller port stuff and like the system dma engine
<tpw_rules>
so idk, did sharp already have this weird 8080 available?
<GenTooMan>
LOL it's hard to know honestly. If we did know what good would it do us? Anyhow that's what I am thinking.
<GenTooMan>
I need sleep so I'll work on doing that.
ZombieChicken has quit [Remote host closed the connection]
ZombieChicken has joined ##openfpga
emeb_mac has quit [Quit: Leaving.]
_whitelogger has joined ##openfpga
_whitelogger has joined ##openfpga
jn__ has quit [Ping timeout: 265 seconds]
jn__ has joined ##openfpga
Jybz has joined ##openfpga
Asu has joined ##openfpga
<ZirconiumX>
ZipCPU: better, thank you!
Jybz has quit [Quit: Konversation terminated!]
moho1 has quit [*.net *.split]
Marex has quit [*.net *.split]
forrestv has quit [*.net *.split]
dfgg has quit [*.net *.split]
moho1 has joined ##openfpga
dfgg has joined ##openfpga
forrestv has joined ##openfpga
Marex has joined ##openfpga
OmniMancer has joined ##openfpga
<OmniMancer>
GenTooMan: what sorts of things do you need to do?
<OmniMancer>
tpw_rules: sorry I had other things pulling me away
rohitksingh has quit [Ping timeout: 250 seconds]
<OmniMancer>
daveshah: is there a reason for nextpnr to generate the packer VCC cell with a LUT init of all 0s except a single 1?
<ZirconiumX>
OmniMancer: a single-bit inverter, maybe?
sensille has quit [Ping timeout: 265 seconds]
<OmniMancer>
but it has 32 (even though the LUT only need 16) bits written out
<OmniMancer>
wouldn't you want a LUT with all 1's so it outputs high regardless of input?
sensille has joined ##openfpga
emeb_mac has joined ##openfpga
jn__ has quit [Ping timeout: 246 seconds]
jn__ has joined ##openfpga
<OmniMancer>
daveshah: nextpnr doesn't have directionality on wires does it?
<daveshah>
No, only on pips
<OmniMancer>
and pips do have a direction?
<daveshah>
Yes, always, from source to dest
<daveshah>
(bidir pips are implemented with two unidir pips)
<OmniMancer>
okay
<OmniMancer>
I feel like I have somehow convinced nextpnr that there is a connection from the middle of an interconnect wire to something where the database only has the end of that wire
<OmniMancer>
since it gives me some pips that are not possible
lopsided98 has quit [Quit: No Ping reply in 180 seconds.]
lopsided98 has joined ##openfpga
lopsided98 has quit [Ping timeout: 250 seconds]
lopsided98 has joined ##openfpga
<OmniMancer>
hmmm, though my list of pips does include that impossible connection for the PIB block, so maybe it works in the PIB block I used for fuzzing :/
<OmniMancer>
hmmm for some reason there is a duplicate of another route there with that name, perhaps the tools were being weird in that block or I have a bug
pie_ has joined ##openfpga
<OmniMancer>
I wonder if this is because that pib block is on the edge of the device so doesn't have neighbours on two sides so gets some strange treatment
<pepijndevos>
OmniMancer, what happens in Gowin that at the edges the wires wrap around
<pepijndevos>
IIRC it's similar on other FPGAs
<OmniMancer>
pepijndevos that would make some sense with what I am seeing
<OmniMancer>
kind of
<OmniMancer>
it just means it probably needs some special handling
emeb_mac has quit [Quit: Leaving.]
<OmniMancer>
This is most inconvenient though :/
Maya-sama has joined ##openfpga
Maya-sama is now known as Miyu
hackkitten has quit [Ping timeout: 252 seconds]
Jybz has joined ##openfpga
Jybz has quit [Quit: Konversation terminated!]
<OmniMancer>
daveshah: are the interconnect to interconnect pips the same in every tile in ecp5?
<daveshah>
Yes but there are some oddities in naming around the edges
<daveshah>
Trellis normalises them for the database
horizon has quit [Read error: Connection reset by peer]
<OmniMancer>
what do their names usually look like?
horizon has joined ##openfpga
<OmniMancer>
I have noticed that there are some cases with two different names producing the same bits
<OmniMancer>
daveshah: I think I might need to make the interconnect fuzzer try several tiles and pick only arcs that produce bits in all of them
OmniMancer has quit [Quit: Leaving.]
<ZirconiumX>
ZipCPU: Another point of confusion: the 8-bit-wide R1/CMD field mentions that it contains the R1 response, which is 48 bits long and has a 32-bit status field
<ZipCPU>
No, just the first 8-bits of any response. For SPI mode, that's often all there is
<ZirconiumX>
"Code length is 48 bits. The bits 45:40 indicate the index of the command to be responded to, this value being interpreted as a binary coded number (between 0 and 63). The status of the card is coded in 32 bits." - Physical Layer Simplified Specification v6.00
<ZirconiumX>
For "4.9.1 R1 (normal response command)"
<ZipCPU>
Yeah, that's the SDIO half of the spec. SPI is a touch different
<ZipCPU>
Here, check out 7.3.2.1 Format R1. It's only 8-bits
<ZipCPU>
Fig 7-9: R1 Response Format
<ZirconiumX>
Right, thank you
nrossi has quit [Quit: Connection closed for inactivity]
<tpw_rules>
ZirconiumX: did you miss elm-chan's docs?
<ZirconiumX>
I did read them :P
<tpw_rules>
alright. i've never actually read the official specs, only that page :P
<ZirconiumX>
ZipCPU: Since you know much more than me about this, should the SD card I/O be insulated by a flip-flop synchroniser chain?
<tpw_rules>
i would estimate no, because it's clocked. i didn't do it for my spi flash engine
<whitequark>
you have to consider the timings of the SD card and the FPGA
<tpw_rules>
that said, i didn't hook it directly to any logic, which i think is what whitequark is trying to get at. it goes directly to a flip flop
<whitequark>
no
<whitequark>
not quite
<whitequark>
the SD card has a clock-to-out delay, and the FPGA has setup/hold constraints
<whitequark>
so if you're clocking the FPGA fast enough, and the SD card is slow enough, that the SD card changes its output right when the FPGA is trying to capture it (on the next cycle), that could cause issues
<whitequark>
i hit a very similar bug on Glasgow, with the FX2
<whitequark>
and had to capture on negedge
Asu has quit [Quit: Konversation terminated!]
<ZipCPU>
ZirconiumX: tpw_rules and whitequark have the right answer. There's no need to run the incoming data through a 2FF synchronizer since it's clocked, and you know when it changes
<ZirconiumX>
Right, thank you
emeb_mac has joined ##openfpga
<tnt>
I was looking at #361, but is there a reason objcopy isn't used to embed binary into the elf rather than compiling a huge C file ?