<lmyers272>
ec: So, any good way for me to contribute at this point / should we do a sort of pair thing over video chat... ???
<ec>
can facetime me if you'd like, I can stuff a camera device somewhere in front of me,
<ec>
if you want to dive into something completely separate from what I'm doing: add a ‘printPrompt’ thingie anywhere user-input is being waited for?
<ec>
spits out “> ” or smth?
<ec>
I'm still working on the stupid calling convention.
<ec>
not sure I got it right.
<ec>
also haven't even *tried* running this yet, pretty sure it's gonna crash and burn; so my next half-hour is ‘figuring out why it doesn't work, once I hit run here in the next two minutes.’
<ec>
Exception 6 [Bad instruction address] occurred and ignored
<lmyers272>
Also, noticed this in the lab requirements: "Each arithmetic operation must be called out by a corresponding procedure from the main body."
<ec>
we did that! :D
<lmyers272>
So... bad instruction address. Did you fix the $s0 thing I mentioned?
<ec>
laughing my ass off btw:
<ec>
that rlwrap is, of course, subsequently wrapping *our* program
<ec>
OUR TERRIBLE ASSEMBLY CALCULATOR HAS LINE-EDITING CAPABILITIES
<ec>
lolol.
<purr>
robotlolita
<ec>
purr: wut
<ec>
yeah, fixed that
<lmyers272>
So then do you think it's our jump table?
<lmyers272>
I'm seeing a complain about the sys call on line 57, a.k.a. printString, about an out-of-bounds address. Is it possible we stomp on $a0 somewhere?
<ec>
that's *gotta* be what it is
<ec>
that's precisely my thought
<ec>
how did you tell it was the like 57 syscall? I was having trouble tracking it down
<ec>
sorry, phone with dad, hadn't had a chance to call him yet today
<lmyers272>
I just run `step` in SPIM.
<ec>
ahhah
<ec>
single-stepping through an entire program: the assembly-equivalent of printf-debugging? :P
<lmyers272>
Oh right, Father's day. We accidentally celebrated that last week.
Rurik has quit [Ping timeout: 244 seconds]
<ec>
pff ur no help, rurik
<ec>
ah
<ec>
ahhah
<ec>
ahhhahah
<lmyers272>
It's our jump table. We get an exception right after our jump on line 285.
<ec>
285 is blank?
<ec>
286 prbz. and yeah. that's what I'm following
<ec>
but it obviously *gets to* the PrintString,
<ec>
so like, the jump table is working: it's getting dispatched through one of the _op functions
<ec>
wait
<ec>
ugh wtf, it fails even if I intentionally trigger opERROR
<ec>
*that* should be printing the static operatorErrorMessage, so, especially-wtf
Rurik has joined #elliottcable
<ec>
do the syscalls depend on anything other than $v0 and $a0? o_O
<ec>
GOT IT
<lmyers272>
What?
<ec>
fixing, but pretty sure: move $a0, $v0 in the debug-print
<ec>
v0 is stomped on
<ec>
yahhhhs that fixed the out-of-bounds
<ec>
oh god damnit nope. just fixed it for erraneous operators.
<ec>
so % 123 works, but + 123 doesn't
Rurik has quit [Ping timeout: 264 seconds]
<lmyers272>
When I try + and step, it makes it to our + operator dispatch, but only after two errors. The first is a bad text read, the second is a bad instruction address and appears to occur inside a sys call.
Rurik has joined #elliottcable
<lmyers272>
And properly prints the input back out.
<lmyers272>
But then eventually goes on to having that error on line 57 indefinitely. At least in the current version I have (which doesn't have your $v0 fix).
<ec>
pushing in a sec. yak-shaving a real debugging function. ಠ_ಠ
<ec>
convention: reserving $a3 *globally*, basically, for ‘a value i want to debug rn’
<ec>
no restoring or saving ever, put it in a3 then jump to printDEBUG.
<ec>
'cuz dunwanna deal.
<ec>
ಠ_ಠ
<lmyers272>
Also, when did Undertale make it to Spotify?
<ec>
ahhhhh idk but ahhhhhhh this song
<ec>
you on Spotify? add me
<ec>
user:elliottcable
Rurik has quit [Ping timeout: 258 seconds]
Rurik has joined #elliottcable
<ec>
weird: can't figure out why it's printing double blank lines here somewhere
Rurik has quit [Ping timeout: 244 seconds]
Rarik has joined #elliottcable
<lmyers272>
Ummm... the Spotify thing looks like it requires a FB connection, and I appear to have lost track of my FB password and have apparently just been using my cached login for the past couple months without thinking about it.
<ec>
so those solve everything except the Real Problem. -_-
<ec>
but yeah debugging is much simpler:
<ec>
move $a3, <something>
<ec>
jal printDEBUG
<ec>
and now I choose to stomp on the t's instead of v's in the print subroutines, lol. encourages good t-hygiene.
<purr>
lollllllllll
Rarik has quit [Ping timeout: 244 seconds]
<ec>
very annoyed that the spim debugger displays the line it *just executed*, instead of the line *it's about to execute*
<ec>
“I'd like you to meet Jal, processOperator.”
<ec>
“Hi, Jal.”
Rurik has joined #elliottcable
<lmyers272>
I'm still seeing the "Bad address in text read" right after our computed jump. Then it launches into exception handling code that isn't ours which itself makes a sys call to print the bad instruction address thing. But on the return from exception it gets right to our plus operator as it should. I have no idea what's going on here; it can't be an off-by-one
<lmyers272>
since we have jumps for other operators before and after it, so it's making the correct jump, but complaining about it anyway. Is it possible SPIM just doesn't like jump tables, i.e. doesn't like us jumping to an address that doesn't match up with a label in the assembly?
<ec>
How the fuck do I examine the stack
<ec>
do I need to write a freaking procedure I can jump to that just prints out the hex values on the stack
<ec>
are you 4 real rn mips
<ec>
even qtspim doesn't seem to have a way?
<ec>
oh wait yeah user stack
<ec>
god, qtspim is ugly
<lmyers272>
At this point do you think it might be appropriate to scrap the jump table and the stack in favor of just hacking everything together with jumps and preallocated buffers where needed? There's nothing in the implementation requirements that says we need to use a stack for our procedures, only that we need to have procedures, which we do.
<ec>
I … fuck, hard decision
<ec>
that's throwing away so much work and will take so much time
<ec>
but hell, debugging this could take more
<lmyers272>
We literally have a little over an hour before the submission deadline. Whichever can get done faster is the best.
<ec>
split effort? I keep debugging this, you take the first steps towards scrapping it?
<ec>
oh god oh god is it really
<ec>
yeah and I'm exhausted to boot
<ec>
review: MIPS word is *four* bytes, right?
<lmyers272>
I can try to hack something together and submit it by the deadline.
<lmyers272>
And yes, MIPS word is 4 bytes.
<ec>
oh wow having this *actual view* of the addresses of the compiled code is invaluable
<ec>
yeah ugh gonna have to stick to qtspim from now on -_-
<lmyers272>
Alright. Messy code hacktastic fun time now...
<ec>
AHHHHHH WTF
<ec>
QTSPIM JUST SWALLOWED ALL OF MY CORES
<lmyers272>
Wow, it has a parallel debugger. It really is advanced.
Rurik has quit [Ping timeout: 244 seconds]
<ec>
lollll
<purr>
lolno
<ec>
nailed it, purr
<ec>
OH FUCKING OH
<ec>
I SPOTTED THIS ERROR AGES AGO AND NEVER FIXED IT
<ec>
lmyers272:
<lmyers272>
Which error?
<ec>
addi $t0, -42
<ec>
add $t0, $t0, $t2
<ec>
… $t0 now contains a 0-index offset for the ASCII.
<purr\GH>
CS350-calculator/master ea645fe ELLIOTTCABLE: + OMG THAT WAS SUCH A CLUSTERFUCK
<ec>
all of them afaict
<ec>
okay: adding a consumeWhitespace *before* dispatching into the jump-table; then going to start on addition/subtraction. you want to do multiplication/overflow?
<ec>
then whoever's done first can do division / div-zero handling.
<ec>
afaict ‘as far as i can tell’
<ec>
also switching processOperator over to use s0/s1 instead of so many t's, because I need to be able to jump around
<ec>
and I don't want to keep track of which of those are getting stomped on.
<purr\GH>
CS350-calculator/master 1822cc6 ELLIOTTCABLE: + saving $s0 and $s1 on stack in processOperator
<ec>
lmyers272: your readInteger won't read anything but digits, correct? it stops advancing $a0 once it reaches whitespace?
<lmyers272>
Correct.
<ec>
and it *doesn't* modify $a0 in place, unlike the restA?
<ec>
any particular reason?
<ec>
lmyers272: status?
<lmyers272>
Not really. Feel free to change it.
<ec>
can still facetime if you want; whatever gets this done fastest
<lmyers272>
I'm hacking away at this on my end with ridiculous negative number and unconditional branch bullshit and such. Just trying to get something that might work.
<ec>
I mean, the jumping thing is 100% working afaict
<ec>
just sayin'
<lmyers272>
Are we still getting the bad instruction address error or is that gone?
<ec>
no lol that's gone
<purr>
lolololol
<ec>
was all the fact that it was trying to jump to un-aligned addresses
<ec>
*no idea whatsoever* how it was successfully getting to the printString instructions O_O
<ec>
because dat shit should have immediately exploded. whatever.
<ec>
the overflow detection in readInteger doesn't seem to function:
<ec>
reading in 1234567874563524135657687 gives me 268501173 :P
<ec>
yes i realize that stomps on $a0 right now, just trying to get readInteger call working >,<
prophile has quit [Ping timeout: 258 seconds]
<ec>
ahhhhh lmyers272 ahhhhhhh I have no idea how your readInteger works
<ec>
trying to follow it to figure out what's going wrong, but I'm having no luck >,<
<lmyers272>
High-level description is: read past all leading 0's, read everything forward into a buffer until I hit the end, then read backwards summing everything up until I hit the beginning.
<ec>
hm k
<ec>
and this was working this morning?
<lmyers272>
I remember testing against a bunch of different integers. Seemed to work. Might have fucked something up somewhere. Not sure it's working for me right here either.
<ec>
fuck
<ec>
fuckbad
<ec>
can't figure out the freaking qtspim debugger
<purr\GH>
CS350-calculator/master 6945c68 Lucas Myers: isojdfsodj
<purr\GH>
CS350-calculator/master 78bb56d Lucas Myers: wertyuio
<purr\GH>
CS350-calculator/master 4c164a5 Lucas Myers: Working!
<ec>
ljharb: wat.
<purr>
beep.
<ec>
-what
<purr>
<alexgordon> elliottcable: 1. seduce isaacs, 2. change the name
<ec>
-what
<purr>
<bluebie> blender is the emacs of vfx.. you don't need to ever leave it's loving embrace
<ec>
-what
<purr>
<brr> elliotcable is *really intelligent*
<ljharb>
wat what
<ec>
-what
<purr>
<whitequark> glowcoil: i dissent, radiocarbon dating is very useful
<ec>
-what
<purr>
<elliottcable> writing *completely* unabstracted Paws is like pulling teeth. from a tiger. with a dildo.
<ec>
-what
<purr>
<vil> elliottcable: we're your fandom, apparently
<gq>
-what
<purr>
<purr> Let it be known that joelteon is indifferent to joelteon.
<gq>
-what
<purr>
<whitequark> no, I figured out your execution model, I just thought it is mortally stupid
<gq>
-what
<purr>
<alexgordon> micahjohnston: lol don't be a whitequark
<gq>
-what
<purr>
<ja> I'll try not to fill up your bot
<gq>
-what
<purr>
<alexgordon> perl is like a good shit. it's been flushed ages ago but the smell still hangs around.
<gq>
-what
<purr>
<prophile> that's because ##C is so full of trolls you could give it a dusting of snow and call it norway
<gq>
beep.
meowrobot has quit [Quit: let us connect our intestines and mutually digest]
wraithgar has quit [Quit: Leaving]
meowrobot has joined #elliottcable
<incomprehensibly>
ec: researching headphones, stumbled into embarrassing audiophile review land where headphones "offer a powdery glow to the cymbal puffs"
<incomprehensibly>
think I've decided on Beyerdynamic DT770 80ohm but I should probs find a place to listen to them before getting them
<incomprehensibly>
ec: sadly due to schedule conflicts, no longer taking programming languages this fall and instead doing AI and NLP
<incomprehensibly>
as well as complex variables
<ec>
incomprehensibly: ‘programming languages?’
<ec>
so you're like filling in the CS minor requirements now that you've done all the math, or …
<ec>
or is ‘programming languages’ like, a >400 level course? because here, it's only like CS 425 or something, and they only cover suuuuuper-basic compiler stuff
<ec>
also:
<ec>
incomprehensibly: Momentum M2s!
<ec>
did very lots tons of research. these are Fucking Excellent headphones, *and* have bluetooth functionality for when you don't care.
<ec>
and terrifyingly-excellent noise-canceling, too.