←2018-11-01 2018-11-02 2018-11-03→ ↑2018 ↑all
00:22:05 -!- tromp has quit (Remote host closed the connection).
00:22:59 -!- tromp has joined.
00:40:23 -!- oerjan has joined.
00:41:48 -!- nfd9001 has joined.
00:46:33 <esowiki> [[Truth-machine]] https://esolangs.org/w/index.php?diff=58177&oldid=58176 * Oerjan * (+2) Undo revision 58176 by [[Special:Contributions/ZM|ZM]] ([[User talk:ZM|talk]]) (No fair undoing *all* the moves. Also, we have a tradition to sort some "1337" names as if they were spelled normally, but maybe not consistently.)
00:48:30 -!- AnotherTest has quit (Ping timeout: 264 seconds).
01:17:35 -!- zzo38 has joined.
01:26:19 -!- zzo38 has quit (Disconnected by services).
01:26:24 -!- zzo38 has joined.
01:40:07 <moony> I'm writing a emulator for the MC88110. Someone please slap me.
01:51:19 <oerjan> @slap moony
01:51:20 * lambdabot loves moony , so no slapping
01:51:31 <oerjan> sorry, didn't work
01:52:27 -!- zzo38 has quit (Ping timeout: 240 seconds).
01:52:54 -!- zzo38 has joined.
01:53:15 <zzo38> Do you know how to uncook Magic: the Gathering puzzles?
02:00:58 -!- nfd9001 has quit (Ping timeout: 246 seconds).
02:04:19 -!- zzo38 has quit (Ping timeout: 244 seconds).
02:13:08 -!- zzo38 has joined.
02:29:35 <zzo38> Hello
02:36:06 -!- xkapastel has quit (Quit: Connection closed for inactivity).
04:00:01 -!- Lord_of_Life has quit (Quit: Laa shay'a waqi'un moutlaq bale kouloun moumkine).
04:07:33 -!- MDead has joined.
04:10:21 -!- MDude has quit (Ping timeout: 268 seconds).
04:10:28 -!- MDead has changed nick to MDude.
05:29:12 -!- oerjan has quit (Quit: Nite).
05:44:48 -!- sleffy has joined.
05:45:47 -!- sleffy has quit (Client Quit).
06:04:49 -!- xkapastel has joined.
07:34:47 -!- tromp has quit (Remote host closed the connection).
07:34:59 -!- tromp has joined.
09:44:31 -!- xkapastel has quit (Quit: Connection closed for inactivity).
12:28:21 -!- xkapastel has joined.
13:33:17 -!- sleepnap has joined.
13:45:23 -!- arseniiv has joined.
15:09:22 -!- moony_ has joined.
15:09:31 <moony_> OpenBSD has an assembler for the MC88100. yaaaay
15:09:42 <moony_> So i have a reference point that I can use to crosscheck everything now
15:10:20 <moony_> https://github.com/syuu1228/openbsd-src/tree/ca0d3073d059b7237a1392dde772265698465272/sys/arch/m88k <<< Reference point! :D
15:18:12 -!- wob_jonas has joined.
15:18:19 <wob_jonas> zzo38: hello. what do you mean by uncook?
15:19:05 <moony_> hi wob_jonas
15:19:58 <wob_jonas> hi moony_. why are you writing an emulator, and are you at least making it very efficient and microoptimized?
15:21:05 <moony_> I plan on it, yes
15:21:17 <wob_jonas> good
15:21:31 <moony_> but i also have to make it accurate as possible, because otherwise it'd be a crappy emulator of an obscure system, and no-one else would be there to make a good one
15:21:48 <wob_jonas> but are you also putting on some impractical constraints that make the micro-optimization hard to do and a waste of your time?
15:22:17 <moony_> wob_jonas: no. Cache emulation in this case, for example, is actually easy and fast (Only 128 lines), so a modern CPU can easily pull it off.
15:22:41 <moony_> and the entire 88k cache, with it's status info, easily fits into a modern CPU's cache
15:23:24 <moony_> even then, emulating 192 different registers with only 16 registers is kinda hard :P (two sets of 64 control registers, 32 GPR, and 32 80-bit FPR)
15:24:02 <moony_> CPU only runs at 50MHZ, but it runs 2 instructions per cycle optimally, so I have to be careful anyways
15:24:07 <moony_> I want it to run at full speed accurately
15:24:48 <zzo38> w-b_jonas: I mean to make the altered version of the puzzle which avoids the cook, which should keep the proper solution or pretty close, and should also try to retain the theme if possible
15:25:09 <moony_> wob_jonas: if you're curious, here's the MC88K serie's manuals: http://www.bitsavers.org/components/motorola/88000
15:25:49 <wob_jonas> moony_: do you have any programs that run on that MC88110 that you'll be able to run with this emulator?
15:26:10 <wob_jonas> zzo38: ah, de-cheese the puzzle. I see.
15:27:36 -!- moony__ has joined.
15:28:07 <wob_jonas> moony__: do you have any programs that run on that MC88110 that you'll be able to run with this emulator?
15:28:16 <moony__> wob_jonas: OpenBSD, duh
15:28:23 <moony__> OpenBSD has a port, hence why i noted it
15:28:26 <wob_jonas> good
15:28:30 <moony__> i can use it as my testcase
15:28:51 <moony__> it also has an assembler and GCC port avaliable, but i'm rolling my own anyways because i can
15:29:27 -!- moony_ has quit (Ping timeout: 256 seconds).
15:29:43 <wob_jonas> moony_: you have checked that Bellard doesn't happen to have an accurate emulator for this system, right?
15:29:56 <moony__> I've looked everywhere :P
15:30:10 <wob_jonas> well sure, if it runs openbsd, then it has to have a gcc port
15:30:46 <wob_jonas> openbsd is implemented mostly in C
15:30:55 <moony__> yea
15:31:02 <wob_jonas> that doesn't mean that it's a well-maintained recent gcc port of course
15:31:15 <wob_jonas> just some gcc port that could more or less compile some stuff at some point
15:31:33 <wob_jonas> if a wizard knew how to invoke it
15:31:34 <moony__> The main difficulty with the 88k is that it supports multicore, but the way it does it is unusual these days: Each "core" is a seperate physical chip
15:31:51 <wob_jonas> that's not that unusual really
15:32:03 <wob_jonas> we only had to put them on the same chip because clock frequencies got faster,
15:32:09 <moony__> Mm.
15:32:28 <wob_jonas> maybe I'm showing my age
15:32:43 <moony__> I'm still in highschool, so maybe you are.
15:33:05 <wob_jonas> I mean sure, these days in mobile phones you put everything in one chip, memory and all
15:33:44 <wob_jonas> but that didn't make sense back when I was young, because individual chip designs cost a lot to start to make, and once they started they could make as many as they wanted for cheap, it's making the design that was hard
15:34:23 <wob_jonas> which is also why ROMs were a bit expensive, so video games could only be produced in large numbers, and there were no large enough volatile memories yet
15:34:33 <wob_jonas> so casettes and disks were eventually used as a workaround
15:34:54 <wob_jonas> and by disks I mean floppy disks, and eventually CDs
15:35:22 <wob_jonas> like for the famicom
15:35:55 <moony__> Oldest thing we have in my house is a gamecube
15:35:57 <moony__> :P
15:36:19 <wob_jonas> I don't have a famicom or other old hardware either
15:36:35 <wob_jonas> well, not as a physical system at least, I can run emulated old systems obviously
15:36:52 <wob_jonas> I don't even have a floppy drive anymore, I got rid of it
15:37:08 <wob_jonas> mind you, this computer I'm sitting at is old, but it's nowhere near that old
15:37:53 <wob_jonas> it's only like 8 years old or something
15:38:13 <wob_jonas> was a great top quality computer back when I got it
15:38:18 <wob_jonas> now it's very obsolete
15:38:42 <moony__> I wish i remembered my XBOX Live password for my 360
15:38:57 <moony__> because my account has Marble Blast Ultra installed, and guess what: Ultra is no longer for sale anywhere
15:39:03 <moony__> :<
15:39:25 <wob_jonas> get a copy in an illegal way then, if you're sure you've already bought it legally
15:39:39 <wob_jonas> or use their customer service to reset the password of your account
15:40:04 <moony__> I literally don't know anything related to the account anymore
15:40:08 <moony__> not even the email used
15:40:09 <wob_jonas> you probably only need to know your name and password and ask them on phone on workdays during business times
15:40:09 <moony__> :<
15:40:15 <wob_jonas> um
15:40:26 <wob_jonas> s/name and password/name and birth date/
15:40:30 <wob_jonas> isn't that how it works?
15:40:37 <moony__> Idk, I'll check when i get home
15:42:22 <wob_jonas> but getting an illegal copy of the software from the internets might still be simpler
15:42:42 <moony__> mk
15:43:11 <wob_jonas> that said, you'd better ask someone who actually knows something about nintendo or game systems, rather than me
15:43:27 <moony__> s/nintendo/microsoft/
15:43:32 <wob_jonas> yeah, that
15:43:34 <moony__> it doesn't matter much anyways
15:43:42 <wob_jonas> I only own a nintendo game boy, no other game system
15:44:03 <wob_jonas> apart from that, at home I only play video games on a PC
15:44:05 <moony__> Marble It Up!, a spiritual successor to the Marble Blast series (Gold and Ultra), is coming out for PC soon
15:44:15 <wob_jonas> although I've played quite a lot on other people's game systems of all brands
15:44:18 <moony__> so it's enough for me
15:44:42 <wob_jonas> well, not all brands
15:45:01 <wob_jonas> I've played on nintendo, sega, and sony, but not on microsoft ones IIRC
15:45:26 <wob_jonas> "spiritual successor" is ... somewhat broad.
15:46:14 <moony__> Well, the game has the same concept and design as the original Marble Blast games, even people from the original dev team helped
15:46:21 <moony__> you could say it's similar to what Sonic Mania is for sonic.
15:48:47 <moony__> it's not a TRUE successor only because GarageGames, the company that owns Marble Blast, doesn't seem to want a new Marble Blast game, probably because of the now small market
15:48:53 <moony__> :P
15:49:34 <wob_jonas> ah yes
15:49:37 <wob_jonas> `? keenlist
15:49:38 <HackEso> keenlist is notification for when Tom Hall acquires the necessary intellectual property rights to create the videogame series Commander Keen: The Universe is Toast
15:50:01 <wob_jonas> the owner of the brand isn't selling the rights, despite that they have no use for it
15:50:11 <moony__> pretty much
15:50:32 <wob_jonas> so instead of one good officially sanctioned games, there are only a lot of fan-made games
15:51:16 <wob_jonas> but none of them made by such a game developer genius as Tom Hall
15:51:52 <wob_jonas> most of the good ones are just modifications of the original games with new graphics and levels
15:52:16 <wob_jonas> which is certainly not what Tom Hall would do if he was allowed to make a new game
15:52:31 <wob_jonas> mind you, they can still be good games
15:52:36 <wob_jonas> it's just not the same thing
16:01:33 <wob_jonas> moony__: at some point, please publish this emulator thing somewhere public, and tell this channel about it too
16:01:44 <moony__> I plan on it
16:02:14 <moony__> One of my silly ideas was to try and make it connect to this channel and let you run stuff on it :P
16:02:52 <wob_jonas> nice. I've done that once, but I haven't written the emulator, I only wrote the connection, and I ran it on a side channel because it was too noisy
16:03:02 <moony__> i know. that DOS bot :P
16:03:20 <moony__> i was so curious i made a lot of said noise :P
16:03:30 <wob_jonas> I'd like to point to schmorp's two crazy projects each one emulating an old system with a cpu: http://blog.schmorp.de/2015-06-08-emulating-linux-mips-in-perl-1.html http://blog.schmorp.de/2015-11-10-emulating-vt102-hardware-in-perl-1.html
16:04:49 <moony__> Glad i learned perl recently
16:04:54 <moony__> (I like perl now. Send help)
16:04:56 <wob_jonas> also to this year's IOCCC winner by Christopher Mills http://www.ioccc.org/years.html#2018_mills
16:05:11 <wob_jonas> moony_: I can't really. I hate perl, but I can't stop using it
16:05:23 <wob_jonas> definitely look at ioccc/2018/mills if you haven't, it's very crazy
16:05:30 <moony__> Perl 6 has a lot of nice things
16:05:41 <wob_jonas> perl 6? ok, now you need help
16:05:52 <wob_jonas> perl 6 is bad for you, stop.
16:06:07 <pikhq> It's true.
16:06:08 <moony__> lol
16:06:13 <moony__> Perl 6 is slow
16:06:23 <moony__> i just use it for quick tasks, like i would with perl
16:06:25 <wob_jonas> are you tied in a room and is someone focing you to type "Perl 6 has a lot of nice things" under duress? can you give an address?
16:06:49 <moony__> Well i'm an insane codegolfer. Sorry, i'm sitting in a study hall typing that, no duress here
16:06:51 <wob_jonas> or at least a country
16:07:08 <moony__> i find writing x86-64 fun.
16:07:20 <wob_jonas> maybe there are charity organizations offering help for addiction issues available in your country
16:07:33 * moony__ is literally prototyping the cache lookup function at this second
16:07:39 * moony__ in x86-64
16:07:44 <wob_jonas> there's no problem with writing x86_64, that can be fun
16:07:53 <moony__> golfing it can be awful
16:07:55 <moony__> :P
16:07:59 <wob_jonas> it's only what you said about perl 6 that scares me
16:08:09 <moony__> no u
16:08:25 <wob_jonas> yeah, me too, and I'm seeing a psychologist about all the issues I have
16:08:37 <moony__> Here, to prove my insanity: The main reason i'm writing this massive emulator project is so i can do codegolf with it
16:08:54 <wob_jonas> oh, so that's why you want an _accurate_ emulator. that's a good reason
16:09:04 <moony__> :P
16:09:25 <moony__> That, and a real MVMe board, or designing my own board, would cost a fortune. So real hardware is out of the question
16:09:40 <moony__> unless someone gifts me one haha (Like that would ever happen)
16:10:36 <wob_jonas> sure! I'm a software guy, I think writing custom software on very powerful PCs is the solution to everything, and often consider custom hardware projects crazy when it seems like they could be replaced by a five line perl script
16:10:51 <moony__> Well, i plan on learning how to make custom hardware anyways
16:11:01 <wob_jonas> or not perl, whatever, a software solution on a PC they already have
16:11:05 <moony__> so maybe someday i COULD make a real system using the 88k if i want to
16:11:17 <moony__> i mean, a 88110 only goes for $20 on ebay, because no-one wants them
16:11:18 <wob_jonas> but I'm tolerant, just because I think they're crazy I won't try to stop them
16:11:28 <wob_jonas> it's their free time and they choose to spend it however they like
16:11:51 <wob_jonas> maybe it's a useful hobby to get into hardware and later design actually useful big hardware, one that does something that you can't just do with a simple program on a PC
16:11:54 <moony__> i wonder what happened to #asm
16:11:59 <moony__> it's become invite only
16:12:06 <moony__> i wanted to check if cmp was slower than test
16:12:22 <wob_jonas> moony__: it's forwarded to ##asm
16:12:33 <moony__> oh
16:12:42 <moony__> and ##asm says i'm banned. I blame freenode mask.
16:12:45 <moony__> :p
16:12:59 <wob_jonas> let me check
16:13:43 <wob_jonas> let me see which ban mask you match
16:13:56 <wob_jonas> oh
16:14:12 <wob_jonas> moony__: ":card.freenode.net 367 nc_jonas ##asm *__*!*@* card.freenode.net 1535082016"
16:14:21 <moony__> RIP
16:14:22 <wob_jonas> moony: renick yourself
16:14:32 -!- moony__ has changed nick to moony2.
16:15:01 <wob_jonas> does that help?
16:15:33 <moony2> mhm
16:16:52 <wob_jonas> note that usually IRC allows you to query the ban list even if you're banned from the channel
16:17:06 <wob_jonas> so if you meet this sort of thing you can check this yourself too
16:17:11 <wob_jonas> not that I don't want to help, just saying
16:17:37 -!- moei has joined.
16:18:49 <wob_jonas> zzo38: anyway, no, I don't know how to de-cheese M:tG puzzles. you can try to ask ais523
16:20:21 <wob_jonas> also, yes, I should continue doing the Oracle dump thingy
16:20:27 -!- moony2 has quit (Ping timeout: 256 seconds).
16:27:25 -!- AnotherTest has joined.
16:34:39 -!- moony2 has joined.
16:37:46 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
17:09:11 -!- moony2 has quit (Ping timeout: 256 seconds).
17:11:57 -!- Essadon has joined.
17:14:49 <esowiki> [[Temporal]] https://esolangs.org/w/index.php?diff=58178&oldid=58076 * Plokmijnuhby * (-265) On second thoughts, I'm making it more like Underload.
17:20:29 -!- oerjan has joined.
17:37:19 -!- hexfive has joined.
17:37:44 -!- hexfive has quit (Client Quit).
17:38:07 -!- hexfive has joined.
18:15:16 -!- oerjan has quit (Quit: Later).
18:48:58 -!- Bowserinator has quit (Excess Flood).
18:49:28 -!- Bowserinator has joined.
19:42:32 -!- Phantom_Hoover has joined.
19:47:03 <arseniiv> oh a time-travelling language
19:48:29 <arseniiv> for me it seems at least a part of these should be equivalent to languages abusing amb or other such nondeterministic retcon stuff
19:50:09 <arseniiv> also I occasionally unforgot about Riemann surfaces: these time-travelling programs could essentially run not on a linear time but some more exotic like two interdependent universes
19:51:07 <arseniiv> what do you think?
19:51:28 <arseniiv> okay I’m going to the past to give myself an idea
19:52:30 <arseniiv> @messages?
19:52:30 <lambdabot> Sorry, no messages today.
19:57:37 <arseniiv> oh lambdabot oh dear / it’s such a thing unclear / to me if you time-travel / or not; I hit the gravel
19:59:05 <arseniiv> it would be nice and all / if you could send me something / from future times to now / because I’ve lost the rhyme
20:11:19 <zzo38> Some television shows have popup messages. Can you get rid of them by recording from multiple channels and then some computer program can be used to fix them?
20:16:28 -!- arseniiv has quit (Ping timeout: 246 seconds).
20:27:13 -!- wob_jonas has joined.
20:28:15 <wob_jonas> I bought myself a frame for eyeglasses! I had my doubts, but I think I chose right. Unless this one is unsuitable somehow, I shall have a fancy new pair of eyeglasses ready by christmas 2018 the latest.
20:31:01 -!- MDude has quit (Ping timeout: 244 seconds).
21:32:30 <moony> Alright, i have a good idea of what i do need and what i don't for a fairly accurate emulator (Mostly™ cycle accurate). But first, nostalgia trip.
21:35:38 <wob_jonas> moony: what peripherials are you planning to support?
21:36:04 <moony> Serial, SCSI drive, and maybe a display.
21:36:10 <moony> Really just adding stuff as needed
21:36:12 <moony> :P
21:36:26 <wob_jonas> wow nice
21:36:41 <wob_jonas> wait, no floppy or casette? or the floppy or casette is on SCSI?
21:36:58 <moony> the MC88100, like it's cousin (the M68k), uses memory mapped peripherals, so i can just put less accurate peripheral emulation in another thread and call it a day
21:37:11 <moony> SCSI drive <<< yes
21:37:11 <wob_jonas> I guess you can have a SCSI floppy drive, and you probably don't even need to make the implementation for that yourself.
21:37:49 <wob_jonas> memory mapped peripherials still need some magic by the emulator for controlling the memory mapping
21:38:32 <moony> yea, but the emulator otherwise doesn't care much about what the peripheral IS
21:39:52 <wob_jonas> sure
21:40:07 <wob_jonas> luckily the peripherial and the OS do most of the work
21:40:15 <moony> mhm
21:40:43 <wob_jonas> and yes, serial line is definitely practical, it's easy to get working and a good way to interact with the program running in your emulated box
21:40:54 <wob_jonas> that's why I used serial console for termbot too
21:41:22 <wob_jonas> and that's why you couldn't use the many DOS programs that insist on communicating directly through keyboard and display
21:41:41 <wob_jonas> most DOS programs are optimized for that, they don't do both because that would cost resources
21:42:19 <moony> also, compared to the time needed to look up memory mapping info and emulate the cache, saying "ok forward this to a async buffer on a IO device" is cheap as hell
21:42:46 <wob_jonas> and these programs I ran were written in the PC era, when a working display (CGA or monochrome) and PC-like keyboard was standard for computers
21:42:51 <wob_jonas> (for DOS computers that is)
21:43:22 <wob_jonas> and the display and keyboard (and mouse) is just more versatile than a serial console
21:43:27 <wob_jonas> fast too
21:43:37 <wob_jonas> moony: sure
21:44:26 <wob_jonas> moony: so have you found good enough technical documentation about the CPU and motherboard that you can use for writing this emulator without having to guess too much?
21:44:45 <moony> The CPU's own manual is great. :P
21:44:58 <moony> I have a paperback copy of the MC88100 manual in my possession.
21:45:12 <wob_jonas> nice
21:45:24 <wob_jonas> how about the motherboard, including memory and IO connections?
21:45:34 <moony> MVMe boards will be a lot harder. I'll probably have to guess at it using what openbsd has in code
21:46:01 <wob_jonas> what kind of memory management does this cpu have?
21:46:14 <moony> Block management and Page management are both supported
21:46:25 <moony> and can be interchanged
21:46:54 <wob_jonas> and fast switch between user and system mode or between processes with different page tables?
21:47:02 <moony> also, memory interface is where difficulty no 1 comes in: the CPU can swap between big and little endian at runtime with a single instruction
21:47:13 <moony> yea, you can change the page table address
21:47:28 <wob_jonas> also, how large are the virtual address space and the physical memory address space?
21:47:46 <moony> physical is 32bit.
21:48:03 <moony> virtual is also 32bit. Entire system is 32bit besides the ""GPU"" and FPU :P
21:48:24 <wob_jonas> I see
21:48:52 <wob_jonas> wait, FPU?
21:49:13 <moony> FPU supports 80-bit precision. (That means i have to use x87 instructions, ewwww.)
21:49:32 <wob_jonas> is the FPU required? can't you just omit it and have the software or OS emulate it?
21:49:44 <wob_jonas> (and run mostly software that doesn't need it)
21:49:46 <moony> It's built onto the chip
21:49:57 <moony> so it's required
21:50:01 <wob_jonas> I see
21:50:04 <moony> it's off by default tho
21:50:23 <moony> so i can pretend it doesn't exist for a very short amount of time :P
21:50:30 <wob_jonas> you don't technically _have_ to use x87 instructions, unless you want fast emulation for the FPU. you might choose to run programs that don't use the FPU much, in which case you can just do something slow.
21:50:48 <moony> i wanna try and make the FPU fast. :P
21:50:55 <wob_jonas> ouch
21:50:56 <moony> i'll probably ignore it early on tho
21:51:04 <wob_jonas> that can be difficult or easy, depending on what the FPU is like
21:51:19 <wob_jonas> and its stupid arcane details too, the ones that rarely come up
21:51:35 <wob_jonas> but still make an accurate emulation (whether in software or hardware) a pain in the ass
21:51:57 <moony> I plan on emulating the MC88110, because suprisingly enough it's *easier* to emulate than it's predecessor. You can pick out details about it here: http://bitsavers.org/components/motorola/88000/MC88110UM_88110_Users_Manual_1991.pdf
21:52:18 <moony> it's predecessor doesn't have the ""GPU"", but it has *more* annoying to emulate quirks
21:53:36 <wob_jonas> it doesn't have that middle age feature where there's a mandatory delay so the result of an instruction can't be read by the next instruction, does it?
21:53:42 <moony> mostly because i have to care a lot more about processing order on the MC88100, because the FPU and the integer unit both share the same register file for some bizzare reason.
21:54:09 <moony> wob_jonas, no. It has pipelining that handles that cleanly
21:54:44 <wob_jonas> the FPU and integer unit sharing a register file isn't a big problem. that's what new x86_64 cpus do too with its SSE registers
21:55:47 <moony> it's a problem when there's only one "slot" to use on said file. It's an exclusive or, either use the integer unit or the fpu, OR you can just have lots of pipeline stalls and lose CPU time
21:55:49 <wob_jonas> the SSE register ops are still mostly in different execution units, but it's the same register file and sheduling and decoding pipeline and memory/cache interface
21:56:16 <wob_jonas> from the instruction set viewpoint it's different registers, but they're effectively handled by the same register file now in newer cpus
21:56:45 <moony> plus, SSE instructions can offset the loss by their vastly greater throughput
21:57:04 <wob_jonas> it didn't use to be that way in older x86_64, there used to be two or three register files, separate for index registers, integer vector registers, and float vector registers, but they got away from that in later archs
21:57:25 <wob_jonas> moony: not just greater throughput, but also in some areas better choice of instructions too these days
21:57:37 <moony> also go look at the MC88100's bus
21:58:02 <moony> it has two buses, the P and C bus. Each bus has to have it's own external MC88200 MMU in order to interface with the same data bus/
21:58:04 <wob_jonas> they're effectively the new general purpose registers, and the RBX etc series of 16 64-bit registers are the index registesr
21:58:45 <wob_jonas> it's not completely like that yet, there's still advantage to using the index registers for some general purpose computations because of the instruction encoding sometimes, but it's tending more towards the vectors
21:59:42 <wob_jonas> heck, in some rare cases you even want to use the vector registers to spill data into them from the index registers when you run out of the 16 index registers, because it's often handled more efficiently than the L1 cache or stack cache
22:00:35 <moony> when intel/amd gives us dedicated instructions to spill indexes into vectors, i'll be happy
22:00:35 <wob_jonas> I think there are even very rare pathological cases when it's worth to spill data into the MMX registers in some crazy loops, though you probably specifically have to engineer the right kind of problem for that to come up
22:00:59 <wob_jonas> moony: they do have specific move and insert and uninsert instructions already, with sometimes short encodings
22:01:10 * moony doublechecks
22:01:25 <moony> i dont remember x86-64 by the back of my hand, so i'm a derp sometimes :P
22:01:28 <wob_jonas> sure
22:01:37 <wob_jonas> and look at new enough documentation, not ancient stuff
22:01:44 <wob_jonas> it helps
22:01:50 <wob_jonas> I could be wrong here too
22:01:55 <moony> I usually just use http://www.felixcloutier.com/x86/
22:01:59 <wob_jonas> I'm sure there are such instructions, but I can be wrong about the details
22:02:16 <wob_jonas> these days I look at the official Intel docs and Agner Fog's docs
22:02:27 <wob_jonas> I used to look at AMD's docs too, but these days prefer the Intel doc
22:02:31 <moony> felix's are literally just autogenned from intel docs
22:02:40 <moony> but with nicer formatting
22:03:03 <moony> anyways, you were correct. http://www.felixcloutier.com/x86/PINSRB:PINSRD:PINSRQ.html
22:03:03 <wob_jonas> moony: sure, but is it recent enough? does it at least show AVX2, even if not AVX512 yet?
22:03:22 <moony> it's currently based on the may 2018 edition of intel's docs
22:03:24 <moony> so yes :P
22:03:39 <wob_jonas> moony: those too, but also look at the 64-bit move between index and XMM instructions
22:04:04 <wob_jonas> ok, I'll look at this felixcloutier docs, or at least bookmark it and look at it later
22:04:22 <moony> wob_jonas, it's more of an instruction reference
22:04:34 <moony> but it's really freaking handy, much easier than sifting through a massive PDF :P
22:05:21 <wob_jonas> the PDF is not ideal, but together with other sources (like Agner Fog's manuals) it's good enough, and it's at least accurate and right from the mouth of those who make the CPU
22:05:41 <wob_jonas> the Intel PDF has at least one typo, I even wrote an email to their support that they'll probably ignore
22:07:26 <wob_jonas> moony: the other relevant ones are http://www.felixcloutier.com/x86/MOVD:MOVQ.html , which move between an index register and XMM register, zero-extending,
22:09:02 <moony> also, just for note wob_jonas, the
22:09:23 <moony> 88k's FPU is quite similar to x86's
22:09:33 <moony> so emulation will be easier
22:09:50 <wob_jonas> but yes, also PINSRQ and PEXTRQ
22:10:30 <wob_jonas> moonyt: to the 387, or to the 8087? there's a stupid crucial difference that can like triple your speed if it's the former.
22:10:46 <wob_jonas> "quite similar" is not enough if you want accurate emulation
22:11:05 <moony> mk
22:11:50 <moony> whats said difference?
22:12:16 <wob_jonas> mostly that the relay 8087 handles the sign of infinities in a stupid way
22:12:31 <wob_jonas> there's some other minor ones too but they don't matter that much
22:12:42 <moony> i'd say it's more similar to the 387
22:12:46 <wob_jonas> the 387 can actually emulate the 8087 behavior, but only if you set some crazy flag that no sane software will set
22:14:08 <wob_jonas> also, the 387 actually has the sanest floating point behavior with respect to NaN representation that I've seen among CPUs. I wish other cpus had the same semantics for NaNs (but not other things, eg. I don't want a register stack or all that stupid state change and 80 bit variables and relative lack of non-floating-point instructions),
22:14:38 <moony> i think you'd like the 88k's FPU
22:14:50 <moony> http://bitsavers.org/components/motorola/88000/MC88110UM_88110_Users_Manual_1991.pdf section 04
22:14:54 <wob_jonas> but alas no, every 'cking architecture has to invent its own NaN representation behavior that's incompatible with everything else, so there's at least four different relatively sane behaviours out there, and that's not counting the ones that just throw their hands up and don't even try to handle NaNs
22:15:11 <wob_jonas> and because of compatibility, none of them can just change the behavior of course
22:16:11 <wob_jonas> moony: I probably won't look at that right now, though I may bookmark it, but in any case I'd like the best behavior in modern fast CPUs that run in my computer, not in some old thing. I can emulate the right behavior too if I can afford some speed loss, I don't need a 88000 for that.
22:16:41 <moony> Mc88110 just fires an exception when a source operand is a NaN, which i think is fairly sane
22:17:10 <moony> properly diffs between nonsignalling and signalling, as well. (Signalling NaNs can have a usermode handler)
22:17:15 <wob_jonas> moony: yes, but can the software mask the instruction?
22:17:19 <wob_jonas> um
22:17:21 <wob_jonas> mask the exception?
22:17:26 <wob_jonas> because usually that's what you want
22:17:31 <wob_jonas> and just check for NaN at the end
22:17:38 <wob_jonas> actually using the exception is a rare case
22:17:40 * moony doublechecks
22:17:50 <wob_jonas> in most CPUs, you can
22:18:24 <wob_jonas> and the CPU has defnite behavior of the result of the operation, sometimes even different result depending on whether the exception is masked or not
22:19:15 <moony> TCFP masks the NaN exception. (TCFP stands for Time Critical Floating Point)
22:19:19 <wob_jonas> eg. for an overflow exception, the result is infinity of correct sign from outside the exception, but the correct value with a constant added to the exponent for the exception handler (they get the result in different ways so there's no ambiguity)
22:20:07 <moony> and you can mask the NaN exception normally as well
22:20:07 <wob_jonas> x87, SSE, and MMIX all have individually maskable optional floating-point exceptions, they just differ in what NaN representation rules they have and some other details
22:20:20 <moony> TCFP mode just disables all but 2 exceptions
22:20:37 <wob_jonas> (I don't recall what AMR does, I looked at it very little, and mostly at the non-floating-point parts)
22:20:53 <wob_jonas> moony: right, that's the usual thing they do
22:21:11 <moony> yea, all FP exceptions are maskable besides 2
22:21:35 <moony> those two being things that only trigger when truly invalid behavior, like a unimplemented floating point instruction, is requested
22:22:02 <wob_jonas> SSE2 also has two flags for not handling denormal values (a flag for reading a denormal as zero, and a flag for giving a zero result instead of a denormal), and a speed hit when it actually has to handle denormals
22:22:19 <wob_jonas> or SSE or whatever
22:22:28 <moony> MC88110 has a similar thing, but i dont see any notes about denormals having a speed it.
22:22:30 <moony> *hit
22:22:32 <wob_jonas> I don't care when it was introduced between those
22:22:58 <wob_jonas> moony: if there's a flag then there's probably some sort of speed hit, or was in older versions of the CPU with a compatible instruction set
22:23:08 <wob_jonas> they wouldn't introduce a flag otherwise
22:23:21 <wob_jonas> it's possible to not have the speed hit but keep the flag for compatibility of course
22:24:06 <moony> oh nvm no flag
22:24:08 <moony> just misread
22:24:16 <moony> it doesn't even support denormals :p
22:24:29 <moony> it DOES fire an exception when they're encountered so software can handle it tho
22:25:40 <wob_jonas> ouch
22:26:16 <wob_jonas> because of its long history, x86_64 has a lot of historical features that you no longer need to use if your code only runs on newer cpus, but that the cpus must support for compatibility because they made sense on older cpus
22:26:46 <moony> ¯\_(ツ)_/¯ at least motorola was nice enough to write the handler for you, they provide it in a software package that is no longer on planet earth haha
22:27:25 <wob_jonas> eg. there are pairs of equivalent SSE2 instructions for bitwise operations on XMM registers that differ in speed depending on whether they're between integer or floating-point vector instructions, the cpu needed to transparently transfer the value to another register file if you used the wrong one, but there's no longer a separate register file
22:27:42 -!- Lord_of_Life has joined.
22:27:42 -!- Lord_of_Life has quit (Changing host).
22:27:42 -!- Lord_of_Life has joined.
22:35:59 <wob_jonas> moony: that's a pity, but no denormal handling in hardware is a compromise that I can understand
22:37:36 <wob_jonas> motorola wanted cheap chips, with the technology back then, it made sense
22:38:09 <wob_jonas> it's in chips today where I want the best behavior, because we could afford it if it weren't for historical compatibility issues
22:50:25 -!- sleepnap has left.
22:50:40 <wob_jonas> heck, even the most annoying limitation of x86_64 is because of historical compatibility: we can't have more than 128 kilobytes of L1 data cache, because more than 8-way cache would have too much latency, and we can't dispatch cache by more than modulo 4 kilobytes of address space, because we have to be historically compatible with 4 kilobyte sized
22:50:40 <wob_jonas> pages.
22:51:42 <wob_jonas> larger page size would be more efficient, but we can't get rid of supporting the smaller pages until some existing software depends on it, and it would be too impractical to have two entirely different L1 caches together, you'd probably have to duplicate the rest of the CPU with it
22:52:04 <wob_jonas> so we won't have a larger L1 cache until we throw away the entire x86 historical compatibility
22:53:52 <wob_jonas> this is harder to replace than the instruction set. x86_64 managed to get rid of at least some parts of the instruction set in true 64-bit mode, and you could get rid of more, but you can't get rid of the paging without throwing away all the compatibility
22:55:25 <wob_jonas> but the good news is, that will probably happen within my lifetime, the way how fast these computer architectures change
22:55:48 <wob_jonas> I'll be happy to learn about the details of a better architecture used in everyday consumer PCs
22:56:09 <wob_jonas> (some computers use ARM, admittedly, but even that is rather old)
22:56:33 <wob_jonas> (and x86_64 is used in the highest performance ones, which is the ones that matter for this)
22:58:13 -!- wob_jonas has quit (Quit: http://www.kiwiirc.com/ - A hand crafted IRC client).
23:08:06 -!- tromp_ has joined.
23:10:16 -!- tromp has quit (Ping timeout: 250 seconds).
23:13:33 -!- sebbu has quit (Read error: Connection reset by peer).
23:13:56 -!- sebbu has joined.
23:31:48 -!- Phantom_Hoover has quit (Read error: Connection reset by peer).
23:33:51 -!- Lord_of_Life_ has joined.
23:35:27 -!- Lord_of_Life has quit (Ping timeout: 240 seconds).
23:35:27 -!- Lord_of_Life_ has changed nick to Lord_of_Life.
23:35:27 -!- Lord_of_Life has quit (Changing host).
23:35:27 -!- Lord_of_Life has joined.
23:35:58 -!- AnotherTest has quit (Ping timeout: 252 seconds).
23:41:15 -!- wob_jonas has joined.
23:42:06 -!- Lord_of_Life has quit (Ping timeout: 252 seconds).
23:42:44 <wob_jonas> Do you happen to know where I can find good reviews of current non-smart mobile phone user interfaces? I want to find the right phone to buy for myself. I have some candidates, but want to find reviews by people who care about similar interface sutff as me.
23:43:17 <wob_jonas> It would be cheaper and faster than to buy a phone and find out that it sucks after a few days of playing with it, like it happened with these stupid nokias.
23:43:51 <wob_jonas> But it looks like I can't find any good reviews.
23:44:43 -!- Lord_of_Life has joined.
23:44:43 -!- Lord_of_Life has quit (Changing host).
23:44:43 -!- Lord_of_Life has joined.
23:44:48 <wob_jonas> I might My current candidate is the CAT B30 dual sim. It is one of these stupid rubber-padded hard to break things with a small display, but if that's the extra I have to pay for to get a sane interface, it's OK.
23:46:59 <wob_jonas> Other candidates are the Myphone 6310 and the Myphone 3310.
23:48:22 <wob_jonas> sadly the 3310 is named such that the number is the same as a very popular new nokia phone (which is named of an older nokia phone, this is really stupid), so it's harder to search for it
23:50:19 -!- copumpkin has quit (Read error: Connection reset by peer).
23:50:34 -!- hakatashi1 has quit (Remote host closed the connection).
23:51:18 <wob_jonas> I totally can't find reviews, so unless someone here can pipe in with some useful info, I'll probably just buy a CAT B30 and try it.
23:51:31 -!- copumpkin has joined.
23:51:41 <wob_jonas> It's definitely not perfect, but I can't get a perfect phone, I know that.
23:51:51 <wob_jonas> I just need one that's not too annoying.
23:52:00 -!- hakatashi has joined.
←2018-11-01 2018-11-02 2018-11-03→ ↑2018 ↑all