klange changed the topic of #osdev to: Operating System Development || Don't ask to ask---just ask! || For 3+ LoC, use a pastebin (for example https://gist.github.com/) || Stats + Old logs: http://osdev-logs.qzx.com New Logs: https://libera.irclog.whitequark.org/osdev || Visit https://wiki.osdev.org and https://forum.osdev.org || Books: https://wiki.osdev.org/Books
sdfgsdfg has joined #osdev
* Ameisen has been frustrated at work
<Ameisen> I've had to do benchmarks on some things that are productivity/related and they take a long time
<Ameisen> I cannot really do anything while they're running
eryjus has joined #osdev
sdfgsdfg has quit [Quit: sdfgsdfg]
<zid> whoopsie, my cpu fan is not spinning
<zid> also ow, 90C heatsinks are hot
<eryjus> no thermal break yet? a little surprised.
<zid> tjmax is 100
<zid> guess I need to reboot, I think I know what caused it at least
zid has quit []
<klange> tjmaxx? I thought they went bankrupt or something (they did not)
<Ameisen> not only did they not go bankrupt, but their max temperature indoors is 100C
<gog> no wonder the "size 4" jeans i got from them felt more like 2's
heat has joined #osdev
zid has joined #osdev
<zid> fixed
<zid> took me a while because apparently my bios refuses to boot the OS if the cpu is too hot
<zid> so I had to wait for the (now working!) fan to cool it down
<gog> were you playing with pwmconfig
<zid> no I was messing with a driver to me me do "out" from userspace
<zid> and apparently it completely dicked speedfan over
<gog> whoopsie
<gog> i cooked a q6600 once but it didn't seem to care just kept on truckin
<gog> i think my old roommate is using it in a file server now
<zid> q6600 had proper thermal limits
<zid> I ran it at 90C all day :p
<gog> nice
<zid> gotta reconfigure speedfan I tried reinstalling it to get its driver working again :(
<zid> Apparently speedfan thinks my CPU is now -60C though for some reason
<zid> I un-genuined my windows too by moving my boot drives around
zid has quit []
zid has joined #osdev
<zid> If they didn't want me to use windows loader to reactivate windows, they shouldn't have made me need to call microsoft, fixed
<Ameisen> maybe you've discovered a way to supercool devices passively
<zid> whatever, it can read the core temps correctly, I just made it track core 0 instead of package
X-Scale has quit [Ping timeout: 268 seconds]
X-Scale` has joined #osdev
X-Scale` is now known as X-Scale
jiChen has joined #osdev
pretty_dumm_guy has quit [Quit: WeeChat 3.3]
freakazoid343 has quit [Ping timeout: 260 seconds]
jiChen has quit [Quit: Client closed]
nyah has quit [Ping timeout: 268 seconds]
kori has joined #osdev
freakazoid12345 has joined #osdev
devcpu has quit [Quit: leaving]
devcpu has joined #osdev
dude12312414 has joined #osdev
isaacwoods has quit [Quit: WeeChat 3.3]
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
[itchyjunk] has quit [Ping timeout: 245 seconds]
[itchyjunk] has joined #osdev
<klys_> curious about something, the linux loopback interface required too much permission for someone's builds and so and so probably has a replacement for that by now
<klys_> specifically the partprobe thing
dutch has quit [Quit: WeeChat 3.3]
radens has quit [Quit: Connection closed for inactivity]
dutch has joined #osdev
<zid> oh a ben eater vid
<zid> doesn't sound super interesting though
<Mutabah> It's the basics of timers
<Mutabah> Pretty simple if you're at our level, but not bad
<zid> I don't think he can demonstrate how sleep *actually* works, on a 6502 :P
[itchyjunk] has quit [Quit: Leaving]
mahmutov has quit [Ping timeout: 268 seconds]
srjek has quit [Ping timeout: 245 seconds]
dude12312414 has joined #osdev
dude12312414 has quit [Client Quit]
<geist> was nice, but yeah
<zid> sleep is sort of a weird thing to do in general tbh
<zid> If you're in a micro you probably *do* want the idle loop, and if you're on a desktop you definitely want to block somewhere for something instead
<geist> well, what he ended up implementing is basically a fairly standard embedded system
<geist> replace the loop with a WFI if the arch implements it and you have somehting that doesn't burn a lot of power
<geist> actual multithreading on 6502 is pretty annoying in particular because you can't relocate the stack (it's always implicitly page 01)
<geist> though i think some implementations have a swappable hardware page there
<zid> For something like that I'd just set up a callback chain
<geist> sure
<zid> rather than "threads"
<zid> just a bunch of tasks that get ran on whatever frequency you want
<moon-child> https://www.youtube.com/watch?v=kRlSFm519Bo more interesting eater video about timers
<bslsk05> ​'Astable 555 timer - 8-bit computer clock - part 1' by Ben Eater (00:27:50)
<moon-child> (at least, so I assume; I didn't watch the other one)
<zid> That's about signal generation
<zid> latest vid is about IRQs
<zid> and delay loops
<geist> actually dealing with multiplexing sw timers on top of hw timers is surprisingly not a topic that comes up here over the years
<geist> either lots of hobbyists dont get to it, or it's trivial enough that most folks that do just figure it out
<zid> most games are written like that tbh
<zid> it's very natural
<zid> you get some callback, like vsync, then you pump off a bunch of events that need to happen on that frame, and go back to sleep
<geist> yah and ifyou have more events for that frame to deal with you can choose to delay them till the nxt one, etc
<zid> yea interrupts just stay disabled
<zid> you end up doing your entire program in the interrupt handler
<geist> i like writing that sort of game engine code. it's very much like kernels when you think about it
<zid> and only ever go idle with interrupts enabled
<geist> that's actually pretty much what ARM sort of intends you to do with cortex-m class hardware
<geist> since they have this very sophisticated interrupt priority scheme
<geist> it's fairly clear they intend for you to just write embedded thigns where multiple tasks == multiple interrupt vectors
<geist> totally doable really
<zid> (The other method is just to do it all before vblank, and just leave everything 'pending' for the vblank callback to finalize, like you double buffer the entire game state, and vblank just does a complicated memcpy)
<geist> you can have a main thats literally for (;;) wfi;
<zid> That latter one is fairly common on gameboy, because of vram being locked at various times and cpu time being limited
<moon-child> sounds like a case where coroutines would work well
<geist> whomp whomp. my windows 10 box just blue screened with PAGE_FAULT_IN_NONPAGED_AREA
<zid> You end up doing "calculate where I want all the sprites to be for the next frame without actually doing any mmio" then vram just copies a data block over the mmio range
<moon-child> but I guess interrupts are not so expensive in embedded?
<zid> s/vram/vblank
<geist> moon-child: in the case of cortex-m on ARM they seemed to explicitly design it such that they aren't, yeah
<geist> and it's quite efficient about dispatching interrupts from other interrupts, etc
<geist> i dont particularly *like* it, because it sort of runs counter to a preemptive system, and sort of gets in your way
<geist> but, it's clear what they were going for
* moon-child nods
grange_c has quit [Quit: Ping timeout (120 seconds)]
<moon-child> incidentally, I came up with a truly horrible scheme for writing signal handlers that call non-reentrant functions
grange_c has joined #osdev
<moon-child> examine call stack. If you find you're currently in a non-reentrant function you wanna call from your handler, figure out the stack entry for its return address. Stash it and overwrite with the address of your fault handler
<moon-child> will run once it's done
<geist> what is sorta interesting is years later after i started playing with ancient VAX hardware did i realize the cortex-m interrupt scheme is almost a direct clone of what VAX did in the 70s
<geist> someone at ARM was clearly a student of classic architectures
<moon-child> s/fault handler/int handler/
<zid> or just old
<geist> well, they're not mutually exclusive
<zid> Don't really need to be a 'student' of the modern era
<zid> Whatever you grew up with is the default and completely natural
<geist> sure
<zid> I bet some kids in 10 years are going to start designing things with bloody mailboxes ;)
<zid> because of the rpi
devcpu has quit [Quit: leaving]
bauen1 has quit [Ping timeout: 260 seconds]
ElectronApps has joined #osdev
devcpu has joined #osdev
ZipCPU has quit [*.net *.split]
Raito_Bezarius has quit [*.net *.split]
acidx has quit [*.net *.split]
stux|away has quit [*.net *.split]
noocsharp has quit [*.net *.split]
doppler has quit [*.net *.split]
warlock has quit [*.net *.split]
nur has quit [*.net *.split]
acidx has joined #osdev
ZipCPU has joined #osdev
doppler has joined #osdev
riverdc has quit [*.net *.split]
catern has quit [*.net *.split]
riverdc has joined #osdev
catern has joined #osdev
bauen1 has joined #osdev
heat has quit [Ping timeout: 256 seconds]
gxt has quit [Remote host closed the connection]
gxt has joined #osdev
xenos1984 has quit [Quit: Leaving.]
Electron has joined #osdev
ElectronApps has quit [Ping timeout: 256 seconds]
nur has joined #osdev
xenos1984 has joined #osdev
<jjuran> klange: Nice DX7 article. Kudos on the bugfix.
dormito has quit [Quit: WeeChat 3.3]
j00ru_ is now known as j00ru
GeDaMo has joined #osdev
adachristine has joined #osdev
gog has quit [Quit: byee]
adachristine is now known as gog
pg12 has quit [Ping timeout: 260 seconds]
scoobydoo has quit [Ping timeout: 264 seconds]
dennis95 has joined #osdev
xenos1984 has quit [Remote host closed the connection]
xenos1984 has joined #osdev
elastic_dog has quit [Ping timeout: 264 seconds]
* enyc meows jjuran
pretty_dumm_guy has joined #osdev
xenos1984 has quit [Quit: Leaving.]
Oli has joined #osdev
Oli has quit [Client Quit]
ravan has joined #osdev
Oli has joined #osdev
[itchyjunk] has joined #osdev
<klange> Ugh, well, I can't quite pin down where this is being so slow, but at least it seems to be both stable and no longer locking everything up, so... new ata driver pushed, I guess.
<klange> I can install doom, I can play doom, I can reboot, and doom is still there
ahalaney has joined #osdev
elastic_dog has joined #osdev
stux|away has joined #osdev
mathway has joined #osdev
<mathway> Hey. Could someone please explain me how types of STDIN buffering, like line-buffering and full buffering, works? I've searched the net a little, but I can only found information about their existence, but not how to work with them and how they exactly work. How there can exist different types of input buffering, when it just issues the read syscall which can't say in advance how many characters
<mathway> there are in input file, or the location of a newline character in it?
<zid> Usually you care more about the reverse
<mathway> What do you mean?
<zid> output buffering
<zid> I can't think of any osdev related stuff that has input buffering
<Mutabah> terminals?
<Mutabah> Sounds like pty logic
<klange> input buffering is generally a tty thing; there's a layer in between smashing your keyboard in the terminal and what actually gets read by the receiving process
<zid> that's output buffering though, shit you write()
<Mutabah> No, it's input buffering.
<Mutabah> Usually raw or line (full buffering isn't really a thing for ptys)
<zid> fflush infact, only works on output streams :P
<mathway> in unix
<mathway> microsoft does specify the behaviour for fflush(stdin)
<zid> They're wrong then, fflush is C
<zid> f* gives it away, posix is read/write/etc, C is fread/fwrite/etc
<mathway> Mutabah, I think there a lot of buffering in the whole computing process
<Mutabah> Oh, there's a LOT
<zid> Yea, thankfully
* zid huges his caches
<zid> hugs* feck
<mathway> However, from the programming perspective, now we speak about buffering inside standard library in case of i/o
<klange> mathway: A tty is configurable, so you can select how it buffers (or doesn't) input. None of this happens in the standard library, the tty layer exists outside of your program.
<mathway> i see that there's different types of buffering when input is from pty, and from file
<zid> the only 'standard library' buffering is the output buffering on newlines from fwrite/puts/printf/etc, which you can configure with setvbuf
<zid> that isn't.. implementation specific, anyway
<zid> some will input buffer so that getch isn't slow as fuck
<mathway> as far as i understand, i cannot control anyway types of buffering of tty or pry inside my program?
<mathway> if i can setvbuf on an input stream, what is the reason?
<mathway> if you say that it has no meaning, since the place where input buffering occurs is inside host environment, not my program
xenos1984 has joined #osdev
<klange> mathway: highly recommend a read of this https://www.linusakesson.net/programming/tty/
<bslsk05> ​www.linusakesson.net: The TTY demystified
<mathway> Thanks, will go read it.
elastic_dog has quit [Ping timeout: 250 seconds]
MiningMarsh has quit [Quit: ZNC 1.8.2 - https://znc.in]
elastic_dog has joined #osdev
MiningMarsh has joined #osdev
dennis95 has quit [Ping timeout: 265 seconds]
Electron has quit [Read error: Connection reset by peer]
ElectronApps has joined #osdev
nyah has joined #osdev
dennis95 has joined #osdev
ravan_ has joined #osdev
ravan has quit [Ping timeout: 260 seconds]
srjek has joined #osdev
mathway has quit [Quit: WeeChat 3.3]
noocsharp has joined #osdev
bauen1 has quit [Ping timeout: 256 seconds]
bauen1 has joined #osdev
sprock has quit [Ping timeout: 260 seconds]
koon has left #osdev [#osdev]
xenos1984 has quit [Ping timeout: 256 seconds]
bauen1 has quit [Ping timeout: 265 seconds]
bauen1 has joined #osdev
ElectronApps has quit [Remote host closed the connection]
ahalaney has quit [Quit: Leaving]
ahalaney has joined #osdev
heat has joined #osdev
bauen1 has quit [Ping timeout: 260 seconds]
bauen1 has joined #osdev
ravan__ has joined #osdev
<heat> is there a better way to not deal with libgcc in x86_64 than multilib?
<heat> due to mcmodel and mno-red-zone issues
<zid> how does multilib help?
<heat> gcc builds all its libraries in all combinations of multilibs
ravan_ has quit [Ping timeout: 268 seconds]
<heat> if you tell it to use mcmodel=large and mno-redzone, it will build (normal, mcmodel=large, mno-red-zone, mcmodel=large & mno-red-zone)
<heat> for libgcc, libstdc++-v3, libsanitizer, etc
<zid> still not seeing how adding multilib helps
<zid> sounds like more libgccs to port
bauen1 has quit [Ping timeout: 256 seconds]
<heat> linking kernel code = links with mno-red-zone & mcmodel=large
<heat> linking user code = links with normal libgcc
<zid> you keep repeating the bit that doesn't explain anything
<heat> how the fuck does it not help?
<zid> why would having x86 libgcc available alongside your amd64 libgcc, help 'deal with libgcc in x86_64'
<heat> multilib != 32-bit
<heat> multilib = build whatever the gcc target tells you to build
<heat> if you tell gcc to compile all its runtime libraries with -m32, it will, but it also works with *any* other option
<heat> the compiler then links you to the correct library according to the options you pass it
<zid> multilib is whether -m32 -m64 and -mx32 work, in gcc speak, fairly sure
<heat> negative
<heat> lots of targets have different multilibs
<zid> for x86_64-*-linux* that's what it means
<zid> I didn't think sparc was relevent
<heat> riscv for example
<zid> rv32gc or rv64gc
<zid> for riscv
<bslsk05> ​gist.github.com: gist:83d8ef0abb0305b34c26972a8f50cc39 · GitHub
<heat> that's t-linux-multilib
<zid> yea, then multiply by total march's
[itchyjunk] has quit [Read error: Connection reset by peer]
<heat> anyway, I can fix the whole "kernel needs a compatible libgcc + crtbegin/end" problem by using multilib when building gcc, but it's not the greatest solution out there
<heat> do real OSes even link with libgcc?
<zid> real OSes just have a working libgcc port, see -linux-
<heat> not for the kernel
freakazoid12345 has quit [Ping timeout: 260 seconds]
<zid> I've never actually tried to build linux for an arch where I'd expect it to need libgcc, but used an -unknown instead of a -linux, actually
<zid> x86_64 I wouldn't expect to need libgcc unless you did 128bit division or something funky, it does 64bit ops natively afterall
<heat> it sometimes does need it for builtins iirc
<heat> and most importantly, constructors
<sham1> And how would Linux do 64-bit division on i386+ without libgcc
<zid> looks like they don't, and hand-roll 64bit division
<zid> https://yarchive.net/comp/linux/libgcc.html this is 20 years old now though
<bslsk05> ​yarchive.net: libgcc (Linus Torvalds)
<heat> you have special 64-bit div functions irrc
<heat> iirc*
<zid> (I also just don't link against libgcc, when it bites me I'll decide what to do)
<sham1> Hmm, it could certainly make things easier for me as well if I just simply ignored libgcc and figured it out later
<sham1> Building gcc would be easier and require less patching of sources and builds at build-time
<heat> fuchsia seems to link in libgcc and compiler-rt though?
<heat> dunno how
sprock has joined #osdev
mahmutov has joined #osdev
<heat> actually no they seem to disable it with -nostdlib
elastic_dog has quit [Ping timeout: 250 seconds]
<sham1> Maybe compiler-rt is more amicable towards mcmodel=kernel and such
<sham1> In that case, that'd be one more reason to stop doing gcc and going with clang instead
<heat> highly unlikely
pg12 has joined #osdev
elastic_dog has joined #osdev
dennis95 has quit [Quit: Leaving]
bauen1 has joined #osdev
heat has quit [Read error: Connection reset by peer]
shan has joined #osdev
<shan> does implementing multitasking require any sort of special hardware?
<j`ey> no
<shan> is there anywhere i could read a high level explanation of how it works?
<shan> does one just use timers and interrupts to make it happen (for pre-emptive multitasking?)
<bslsk05> ​wiki.osdev.org: Brendan's Multi-tasking Tutorial - OSDev Wiki
<shan> eryjus: thank you
<j`ey> timers, interrupts, exits from syscalls
<shan> what do you mean, exits from syscalls o_o
elastic_dog has quit [Quit: elastic_dog]
elastic_1 has joined #osdev
<shan> also, i'm not actually writing an operating system, i was just curious how multitasking works
elastic_1 has quit [Client Quit]
<j`ey> as in, after a syscall, as the kernel is going to enter userspace, it might reschedule
<shan> ohhhhh
<shan> that makes sense
elastic_dog has joined #osdev
<catern> it occurs to me that running all the tests of a large system under SCHED_FIFO would be a good practice both to 1. ensure there's no busy-looping in the system and 2. massively reduce test flakiness/nondeterminism
dude12312414 has joined #osdev
bgs has quit [Ping timeout: 256 seconds]
amazigh has left #osdev [WeeChat 2.8]
bgs has joined #osdev
bgs has quit [Read error: Connection reset by peer]
bgs has joined #osdev
srjek has quit [Ping timeout: 268 seconds]
pieguy128 has quit [Quit: ZNC 1.8.2 - https://znc.in]
pieguy128 has joined #osdev
xenos1984 has joined #osdev
radnic has joined #osdev
sprock has quit [Ping timeout: 250 seconds]
<riverdc> anyone have recommendations for x86 instruction encoding libraries? preferably in C
<riverdc> I'm not sure how to use just the instruction encoding from LLVM without commiting to using the LLVM IR
<geist> was gonna tell heat, fuchsia sidesteps the -mno-red-zone for the kernel by simply not linking in libgcc
<geist> otherwise wold have to have a multilib for it
<geist> or, as i was pondering the other day, forcing every x86 exception through an IST and then manually building a stack frame that's red zone aware
<geist> seems like it's very doable, but would just require extra work on every exception
sprock has joined #osdev
<sham1> geist: do you also happen to not link against libgcc on i686+?
<geist> fuchsia does't run on x86-32
<sham1> Fair enough
<sham1> That side-steps the issue nicely
<geist> 64bit only. aarch64 and x86-64 are both pretty libgcc clean. you can more or less never worry about it and unless you're using lots of 128 bit math or whatnot you'll probably never hit it
<geist> or there's one or two functions you can just manually implement
<geist> riscv64 too
brenden has joined #osdev
<sham1> I don't even know how you'd do 128-bit math, probably __int128
<Arsen> that's about right
<Arsen> doesn't libgcc also hold some stack walking things
<sham1> Of course one way to avoid all this nonsense is to have a unikernel not built in C
<sham1> Or well, any kernel not built in C
<Arsen> clearly, c++ solves this
<sham1> Or C++
<sham1> If we want to be knobs about it
<Arsen> though, seriously, how does the language impact this?
<sham1> Well the language affects it in therms of the compiler used
<sham1> You could always not use GCC and that might solve it
<Arsen> doesn't clang also do this?
<Arsen> I'm not aware of any compilers that aren't llvm or gnu and are a good choice
<sham1> With compiler-rt yeah, and I don't know how well that supports being used with mcmodel=kernel
<geist> sham1: yes __int128
Oli has quit [Ping timeout: 268 seconds]
Oli has joined #osdev
<kingoffrance> riverdc, no but i have "instruction_decoder" "instruction_encoder" libraries for that purpose. just havent implemented any backends yet :D
<kingoffrance> i mean, i didnt really look, but i want such a thing eventually
GeDaMo has quit [Remote host closed the connection]
<kingoffrance> the only thing i care about there is have a plaintext specification format (or "configuration file") so new things can be added without writing code. so..."yak shaving"
<kingoffrance> and then make other things use those libraries
<kingoffrance> e.g. assembler, whatever else
<kingoffrance> if i was going to copy something, i would just want to avoid hardcoding
<sham1> Those poor yaks
<j`ey> that's what LLVM (tablegen) and GCC (I forgot.., .md files I think)
<kingoffrance> ^^ yep, gcc had some kind of lisp-ish-inspired IIRC
<sham1> Ofc
<kingoffrance> i dont want to write a compiler, so i avoid it...but that seems simple, just drudgery mostly.
lg has quit [Ping timeout: 268 seconds]
diamondbond has joined #osdev
diamondbond has quit [Read error: Connection reset by peer]
elderK has joined #osdev
sprock has quit [Ping timeout: 260 seconds]
lg has joined #osdev
srjek has joined #osdev
radnic has quit [Read error: Connection reset by peer]
dormito has joined #osdev
dormito has quit [Client Quit]
dormito has joined #osdev
<riverdc> kingoffrance: looks like 'keystone' has assembler infrastructure but I don't think I want to depend on that either
<riverdc> I guess I'll succumb to my NIH syndrome and do it myself for now
<j`ey> building your kernel in itself?
<j`ey> oh, no, block layer stats
brenden has quit [Quit: leaving]
<klange> Just trying to install gcc, it's now written about 7GiB of stuff, though it's only flushed out about 120MB to disk. I have no idea what it's actually doing.
<j`ey> uh oh
srjek has quit [Ping timeout: 250 seconds]
<klange> It's _probably_ an issue with the ext2 driver and not the disk driver? I've never actually tried to unpack this tarball through the ext2 driver and it is a _doozey_.
<klange> and it just failed to create a directory https://klange.dev/s/Screenshot%20from%202021-11-16%2008-02-52.png
<klange> or it tried to put too many files in that directory, lots of possibilities
devcpu has left #osdev [#osdev]
<klange> I'm obviously doing something insanely stupid because it goes through like 600MB of writes... despite only having like 18MB of stuff to write at the end of the day when installing quake https://klange.dev/s/Screenshot%20from%202021-11-16%2008-09-13.png
rustyy has joined #osdev
ahalaney has quit [Quit: Leaving]
vdamewood has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<kingoffrance> riverdc, my problem is i more or less have a "marked up" "intermediate" C due to pragma madness :D but i dont want to write by hand. so if i ever did want a compiler, i need: 1) something to parse C to my "intermediate representation" 2) "IR" either can output more C (what i will do now, functionally-equivalent to macros essentially) or try to transform that to assembly, or maybe another IR between.
<kingoffrance> thats why i postpone that...i could maybe "join in the middle" but i'd need something to parse C first, i dont want to write "IR" by hand :D
sprock has joined #osdev
<kingoffrance> if i get enough separate pieces maybe i can join them, but i have enough to do for now
<kingoffrance> so, an assembler, i would still be missing 2 pieces at least.
<kingoffrance> i'd like an assembler to assemble at run-time though :D it just doesnt get me all the way
freakazoid12345 has joined #osdev
<kingoffrance> and, i dont know, maybe go higher and just skip C altogether, other than "IR" form. i can leave that door open for now, dont know if i'll ever get that far
<kingoffrance> its ilke that lol [???] -> IR "C" -> ??? -> assembler
<riverdc> kingoffrance: I'm in a similar position, although more due to geting tired of writing out tagged unions by hand and doing pattern matching by hand than pragma madness
<kingoffrance> well what do you do, or you are still deciding ?
<kingoffrance> pragma is not really madness, its just...you can go #pragma magic_start ??? #pragma magic_end and go wild lol
<kingoffrance> you can stick any language between those you want