<bslsk05>
wiki.osdev.org: Setting Up Long Mode - OSDev Wiki
<sham1>
Whether your code is within real more or protected mode really depends on how you've booted up. Hell, you might even be directly in long mode's compatibility submode or even the 64-bit submode
<ilovethinking>
uhhh well i booted with qemu -kernel, nothing else lol
<sham1>
Like if you're using GRUB for example, you'll be in protected mode
<sham1>
Okay, then you're in protected
<ilovethinking>
thanks
<ilovethinking>
also a question related to the forums, wtf does "you are not a member of the require phpbb group"? i have an account but idk how to join the wiki grou[
<kof123>
https://github.com/madler/zlib/tree/master/contrib/puff Overlapped copies [...] are allowed and common. You should not use memcpy() since its behavior is not defined for overlapped arrays. You should not use memmove() or bcopy() since [...] their behavior -is- defined for overlapping arrays, [...] to do the wrong thing
<bslsk05>
github.com: zlib/contrib/puff at master · madler/zlib · GitHub
* kof123
.oO( memcpy_yes_i_mean_to_overlap() )
theboringkid has joined #osdev
theboringkid has quit [Client Quit]
biblio has joined #osdev
_xor has quit [Read error: Connection reset by peer]
_xor has joined #osdev
node1 has joined #osdev
<node1>
Hi
<node1>
What is the method for determining the last address of the main memory in hexadecimal when using Linux.?
xvmt has quit [Remote host closed the connection]
xvmt has joined #osdev
Left_Turn has joined #osdev
anbdummy has quit [Quit: WeeChat 3.8]
anbdummy has joined #osdev
theboringkid has joined #osdev
node1 has quit [Quit: Leaving]
<mrvn>
Other than strings when do you copy stuff with overlaps?
lav is now known as pavlovs-cat
pavlovs-cat is now known as lav
theboringkid has quit [Quit: Bye]
<kof123>
you are supposed to gracefully not ask that and instead valiantly jump to benchmarking various memcpy_overlap()
<kof123>
a new variant!
ProblemChild is now known as EthicsGradient
theboringkid has joined #osdev
theboringkid has quit [Read error: Connection reset by peer]
theboringkid1 has joined #osdev
theboringkid1 is now known as theboringkid
smpl has quit [Ping timeout: 248 seconds]
[itchyjunk] has joined #osdev
Patater has quit [Quit: Explodes into a thousand pieces]
Patater has joined #osdev
brunothedev has joined #osdev
Terlisimo has quit [Ping timeout: 265 seconds]
Terlisimo has joined #osdev
heat has joined #osdev
theboringkid1 has joined #osdev
bauen1 has quit [Ping timeout: 246 seconds]
theboringkid has quit [Ping timeout: 246 seconds]
theboringkid1 is now known as theboringkid
bauen1 has joined #osdev
Jari-- has joined #osdev
<Jari-->
hi all
terse has joined #osdev
bnchs has quit [Read error: Connection reset by peer]
<brunothedev>
Jari--: hi
bauen1 has quit [Ping timeout: 255 seconds]
theboringkid has quit [Quit: Bye]
sortie has quit [Ping timeout: 250 seconds]
brunothedev has quit [Quit: WeeChat 3.8]
sortie has joined #osdev
Celelibi has quit [Read error: Connection reset by peer]
nyah has joined #osdev
Celelibi has joined #osdev
elastic_dog has quit [Killed (platinum.libera.chat (Nickname regained by services))]
elastic_dog has joined #osdev
ilovethinking has quit [Ping timeout: 276 seconds]
heat has quit [Remote host closed the connection]
heat has joined #osdev
\Test_User has quit [Quit: .]
\Test_User has joined #osdev
\Test_User has quit [Quit: ..]
\Test_User has joined #osdev
nanovad has quit [Quit: ZNC 1.7.5+deb4 - https://znc.in]
nanovad has joined #osdev
terse has quit [Ping timeout: 260 seconds]
ilovethinking has joined #osdev
<ilovethinking>
hello
<ilovethinking>
so basically after entering long mode and when setting the segment registers, some people set all of them to gdt.data, and others set it to 0
<ilovethinking>
osdev wikii sets it to gdt.data and phil opp's guide sets it to 0
<ilovethinking>
eh i guess ill just set all fo them to 0
<zid>
rdrand, fsgsbase, bmi2, clzero are the ones in there I recognise and know are useful that I don't think I had before
dutch has quit [Quit: WeeChat 3.8]
dutch has joined #osdev
<mrvn>
gog: There is no "invalid" for fs/gs. You just might not like what they contain. E.g. they might allow the wrong CPL access. So you should set them for security. Setting them to 0 give an error on use and setting them to data makes them NOPs.
bauen1 has quit [Ping timeout: 255 seconds]
<mrvn>
gog: and in long mode the MSRs override loading them because they set the full 64bit base.
<mrvn>
override? Accompany? Are any of the remaining bits valid? check the docs.
<gog>
mrvn: makes sense
<mrvn>
Now I wonder if loadin the NULL descriptor and setting fsbase makes FS work or fail.
<mrvn>
I assume at least the CPL is still needed.
<mrvn>
.oO(but I've been wrong before)
<mrvn>
Note: loading 0 takes an exta opcode, the data you already have in a register for loading DS.
<geist>
are we talking about 64 bit mode or not?
<zid>
gs kinda useful to have set though, if you ever wanna do IRQs
<geist>
in 64bit mode you absolutely can set fs and gs to zero, and the underlying fsbase stuff works fine
<zid>
fs is for noobs who like threads
<geist>
so generally that's the strategy on 64bit kernels: set ds/es/fs/gs/ss to zero and if user space sets them to anything else, just set them back to zero
<geist>
ie, it's not valid user state
<geist>
but in 64bit mode that's independent of what is in the fs/gsbase MSRs
<geist>
basically completely vestigial
<geist>
(cs isn't exactly vestigial, it still defines what mode the cpu is in)
<mrvn>
geist: do you reset es/fs/gs on every task switch
<mrvn>
?
<geist>
yes
<geist>
and ds
<geist>
and ss
craigo has quit [Quit: Leaving]
<mrvn>
So any program that sets segments and uses them then randomly fails after the first task switch?
<geist>
correct
<geist>
because it's simply defined as not being part of the user space state. they can fuck with them if they want, but it gets whacked back to zero
<mrvn>
I think last decade when I tried x86_64 I saved and restored them.
<geist>
fairly certain that's not unique and other systems do it too
<geist>
there's probably at best security issues with allowing the kernel to save/restore them, because even if it's ignoring it in 64bit mode, it still would end p loading the shadow state, etc
<geist>
i betcha there's some dumbass microarchitectural problem with that somewhere
<geist>
it's ne thing for user space to set the regiter and the cpu loads the shadow state out of the GDT, but another thing to then have ring0 code do the same load/reload for user space
<geist>
so it's much safer to have ring0 code nevere put anything but 0 in them
<mrvn>
it would be a way to detect a task switch. Might be usefull for micro benchmarks. If es == 0: ignore run
<geist>
there are other ways to detect it
<geist>
also i forget the precise detail, but SS gets hard set to 0 in some particular case, in an interrupt handler
<geist>
so tere's already a case where you can't avoid it, because hardware does it already
<mrvn>
geist: iirc the TSS sets the SS
<geist>
again 64bit mode subtly hanges a bunch of that
<geist>
TSS64 doesn't have a SS field
<geist>
it's just 7 ISTs
<mrvn>
geist: sets it to 0
<geist>
clarify.
<mrvn>
when you load a stack pointer from the TSS then iirc the SS is reset too
<geist>
yah. i thought there was a more subtle case too, even ring0->ring0 where the SS gets reset
<geist>
basically, SS is a goner already. hardware will basically set it to 0 in a way that user space could observe
<mrvn>
maybe. But at least the stack fault has to reset SS in case that was the reason for the fault.
<geist>
except it's not a reason for the fault in user space, because it's not used
<mrvn>
user space could be 32bit
<geist>
yes i'm 100% talking about 64bit onyl
<geist>
with 32bit it's now a mix of both, and if you're context switching 32bit tasks, *then* you ave to save all this state
<geist>
but that's 100% a different discussion
<mrvn>
Ahh, that's also the reason for save/restore of es/fs/gs, 32bit user space.
<geist>
bingo
<geist>
that's also why the hardware *does* still load the shadow bits of a GDT segment when you load a segment register, *even in* 64bit moe
<geist>
because you may be setting up the state for when you switch to 32bit mode
<geist>
and you want the hardware to already be primed for it
<mrvn>
.oO(but not wait for it unless you do)
* gog
meows in 32 bits
* mrvn
breaks gog into 32 bits.
<geist>
so the hardware s still active, but in 64bit mode it simply ignores the results of what you loaded into the shadow state
* Ermine
pets gog
<moon-child>
32-bit gog implies the existence of long gog
<Ermine>
ggoogg
<geist>
so yeah a 64bit kernel that supports a 32bit user space has to deal with both cases
<geist>
but at least when it's in 64bit mode the state doesn't matter so much. so you'd proably have in your context switch routine code to explicitly zero the segment registers if the thread is known to have a 64bit user space
<geist>
and presumably you dont provide a mechanism for a thread to switch states (though i guess you could, via some syscall)
biblio has quit [Quit: Leaving]
<geist>
haha long gog
linearcannon has joined #osdev
<gog>
there is only short gog
linear_cannon has quit [Read error: Connection reset by peer]
<mrvn>
There is at least one: execve()
heat has joined #osdev
<mrvn>
If you had one to switch a running process then you would need some flag in the executable to map the process in the lower 4G only or things would go bad.
<heat>
im bac
<mrvn>
heat: winter is coming
<moon-child>
hi bac
<zid>
we missed you
<zid>
I'll lock on first next time.
<moon-child>
I'm moon-child
<zid>
heat is so drunk he's literally just the concept of BAC
<mrvn>
don't breath on a candle.
<heat>
how does the moon have a child
<heat>
does it have a penis and/or vagina
<mrvn>
how does the child feel when their mother disappears once a month?
<zid>
it means his mother was a hippie
<heat>
or did you get starfished into existence
<sakasama>
mrvn: Those were always the best days for me.
<mrvn>
heat: when a commet really really loves the moon and smacks into it with enough force a bit of moon will break of and become a child.
<mrvn>
On that topic: How do flat earthers explain away the phases of the moon?
<moon-child>
one of the lizard people curls into the fetal position and rolls across the surface of the projector
<mrvn>
.oO(maintainance cycle for the light bulbs)
<geist>
mrvn: hmm, that is interesting. i assume there's no limitation of execing a binary of another bitness
<geist>
never thought about that
<mrvn>
geist: the limit really is just that you can't address anything above 4GB. Even if you map the higher pages into the lower 4GB the address would be all wrong. Unless the code was compiled for the lower address and you are just mapping it there yourself before switching.
<geist>
saure, but since the aspace is getting swapped out the kernel can basically just reconstruct it with the new limitation (or lack of in the case of 32 -> 64)
<mrvn>
It would be strange but you could have a 64-bit dynamic loader that loades 32-bit code and then switches.
<geist>
but i guess it still has to keep the same PID, it just has to switch the mode of the thread
<mrvn>
oh, you ment execve()
<geist>
yah
<geist>
this is no real big deal, but it is the case where a thread would need the kernel to switch its mods
<geist>
mode
<mrvn>
I think the code doesn't really care if it's 64bit or 32-bit. You load the new executable (the INTERP at least) into memory and then copy the PID and open FDs into the new task struct and keep the old task struct for cleanup purposes.
<geist>
yeah mostly just data structures that might need to be tweaked int he kernel
<mrvn>
Should be all the same for 64bit -> 64bit, 32bit -> 64bit or 64bit -> 32bit.
<geist>
i believe we're violently agreeing
<mrvn>
yep. It's a fun thing though to implement that switch.
<mrvn>
Also: don't forget x32. long mode with zero extended 32bit pointers.
<geist>
yah, aside from limiting the aspace, i wonder if there's anything else the kernel needs to do for that
<geist>
probably not
<mrvn>
Nothing I'm aware off. It's real simple to implement.
<geist>
yah we've talked about it off and on for fuchsia, but both x86 and arm, but never did it. mostly a toolchain issue
<geist>
i dont think the kernel needs any tweaks, since we can just in user space limit the aspace via subdividuing the root VMAR
<mrvn>
But if you don't start with that in the design then retroactively changing all the places the kernel allocates and returns some address can be hard.
<geist>
yah zircon doesn't have the problem sicne the kernel never allocates something arbitrarily like that. it's capability based, so you're always allocating within a container, and by default the starting container is the entire aspace
<geist>
but you can subdivide it such that you limit the aspace to 0-4GB by just splitting the root vmar and then throwing away the top part
<geist>
now there's no handle for anything in user space to map anything > 4GB, even if it wanted to
<mrvn>
any struct with a pointer in it shared between user/kernel needs handling.
<geist>
not so sure, because either it's mapped or not. if it's not mapped then usual mechanism will handle it
<mrvn>
I'm talking about the space it takes. The sizeof(struct) differs.
<geist>
it's as you say, only in cases where thek ernel allocates space in user space aspace. needs a limiter of some sort
<geist>
oh. hmmm. yeah that's true
<heat>
linux has learned many lessons there
<geist>
i dot think we have any of those in zircon, but it's a thing, yeah
<mrvn>
I'm thinking stuff like IO vecs for readv()
<heat>
you won't find any new structs without fixed size members
<geist>
ah yeah. iovec. that's a problem. *or* you declare that even in x32 mode it's still 64bit iovecs
<geist>
yah. i'd probably declare somethingl ike a k_iovec and then hard u64 it
<mrvn>
and let the libc handle the change from char* to u64.
<geist>
for zircon at least i think that may be the only real place where a pointer goes across that boundary. also size_Ts, but we can just declare that they're 64bit too
<geist>
r at least i guess the other way of doing it is to declare a x32 world to be entirely a user space concern. and it's user spaces problem to bump it up to 64bit values when crossing syscall boundary
<mrvn>
It's too bad C doesn't have a Must-Be-Zero type. Maybe you could abuse the nullptr_t for that.
<geist>
it's not like it's transparent anyway, because by definition x32 is a 32 bit limited 64 bit ISA
<nortti>
mrvn: for explicit padding?
<mrvn>
geist: that's what I did. The libc has a bunch of stuff it pretties up for the kernel anyway. What's 4 or 5 pinter to u64 converts more?
<mrvn>
Assuming the implementation uses 0 for NULL.
EthicsGradient has quit [Quit: brb]
EthicsGradient has joined #osdev
EthicsGradient has quit [Client Quit]
EthicsGradient has joined #osdev
foudfou has quit [Remote host closed the connection]
<bnchs>
hiii
<geist>
'lo
ilovethinking has quit [Ping timeout: 265 seconds]
<heat>
i'm taking this covid time to finally write the ebpf interp
<mrvn>
*this* covid time?
<heat>
ebpf looks like it maps very well to hw
<heat>
probably because this time they did want something more generic
<heat>
that is indeed designed to be jitted, that is
<heat>
yes mate i have covid
<mrvn>
Must be mild if you are still coding. get better anyway.
<EthicsGradient>
heat: sorry mate get well soon mate
<heat>
thanks
<heat>
i've been mostly ok but 1st day I was feverish as shit
<heat>
got up to 39C this morning :v
<EthicsGradient>
heat: i had 39C fever on the first day when i had it too
<EthicsGradient>
was rough
smpl has quit [Ping timeout: 248 seconds]
brunothedev has joined #osdev
<brunothedev>
how does microkernel works? 1. How does loading works, i've seen things like loading .so files in weechat, but it still weird for me 2. How do you load a filesystem driver without the filesystem?
foudfou has joined #osdev
<GeDaMo>
'microkernel' doesn't have to mean the filesystem driver isn't loaded along with the kernel, it means it's not in the same protection level
<danlarkin>
you can bundle the code in the same binary, but just run part of it in userspace
<GeDaMo>
The bootloader can load everything necessary
<brunothedev>
microkernel is usually separated into multiple files, like minix have a lot of "*.gz" files
<gog>
so does linux
<gog>
a microkernel is a squishy concept anyway
* lav
is a squishy concept
* gog
squish lav
<lav>
uwu
foudfou has quit [Remote host closed the connection]
foudfou has joined #osdev
Piraty has quit [Quit: -]
<brunothedev>
the fact that i have vim, neovim and emacs on my dotfiles makes me fear when i walk down a road
GeDaMo has quit [Quit: That's it, you people have stood in my way long enough! I'm going to clown college!]
<gog>
imagine using anything but ed smh
<brunothedev>
ed is bloat, i write c programs to acess the file and change it
<lav>
there should be ed-mode for emacs
<gog>
how do you write the c file tho
<brunothedev>
gog: the "echo" command, every time it fails, i rewrite everything
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
[itchyjunk] has quit [Remote host closed the connection]
[itchyjunk] has joined #osdev
Piraty has joined #osdev
dude12312414 has joined #osdev
EthicsGradient has quit [Quit: weechat did a weird brb]
EthicsGradient has joined #osdev
foudfou_ has joined #osdev
zxrom_ has joined #osdev
foudfou has quit [Ping timeout: 255 seconds]
zxrom has quit [Ping timeout: 255 seconds]
IRChatter has joined #osdev
foudfou_ has quit [Remote host closed the connection]
foudfou has joined #osdev
slidercrank has quit [Ping timeout: 276 seconds]
zxrom_ is now known as zxrom
brunothedev has quit [Quit: WeeChat 3.8]
inegatives has quit [Quit: inegatives]
brunothedev has joined #osdev
<brunothedev>
you know what? I am gonna write my own bootloader
<bnchs>
brunothedev: how are you gonna write one?
<brunothedev>
bnchs: probably an MBR bootloader that loads another bootloader
<brunothedev>
aka. chainbooting
dude12312414 has quit [Quit: THE RAM IS TOO DAMN HIGH]
<geist>
yah usually microkernels have some sort of secondary loader that can load both the kernel and at least critical driver processes at boot
<geist>
or, you use some sort of ramdisk for the initial boot system, which is why linux + everything in a module + initrd kinda looks like that if you squint at it
<geist>
difference there of course is linux modules will evcentually run at ring0, whereas a microkernel functionally the same thing runs in user space
<geist>
so the tricky part is bootstrapping the very first process
<heat>
why is the ebpf verifier a single 17kLOC file
<geist>
can be done by linking it as a flat binary that the kernel knows how to load, or the secondary loader puts into ram so the kernel branches into it
<geist>
then from then on out all further user space proceses are started from that one
ZombieChicken has joined #osdev
<mjg>
hm
<mjg>
sup mofos
<mjg>
there are at 2 least 2 distinct G papers pointing out detrimental effects of i-cache pressure
<mjg>
and yet G deploys golang binaries, which are all statically linked
<heat>
hi mjg
<mjg>
this gotta be PESSIMAL on that front
<heat>
what does that have to do with icache pressure
<mjg>
they all carry "libc"
<mjg>
instead of sharing it
<mjg>
memset et al
<heat>
yes and realistically how much do you actually share in terms of TLB/icache?
<mjg>
i'm assuming different binaries here
<moon-child>
1. probably, they consider the organisational advantages worth it. Also, go is slow mostly because they wrote their own compiler and sucked at it, not because of i$
<moon-child>
2. probably go is usually deployed by them as one big server, so it doesn't really have anything to share with
<zid>
I bet google also mostly runs things on 96 core machines or whatever these days, and the icache hit rate is low anyway
<heat>
and how does this affect things if you consider that shared linking has shit codegen
<zid>
so making it worse to make development time cheaper is fine
<mjg>
i once more refer you to their papers, which claim a 1% win from icache == millions of dolars in savings bro
<moon-child>
oh, go gc is also crap
<mjg>
:]
<moon-child>
prioritising latency above all else
<zid>
that's what papers are for
<mjg>
all the papers also way postdate go
<zid>
not what businesses actually do
<moon-child>
which might almost make sense for interactive stuff, but which makes no sense at all for network stuff
<mjg>
their papers claim it is all taken from real prod
<zid>
I'm sure the data is
<zid>
and I'm sure the calculation is accurate
<mjg>
moon-child: i don't know the realities of golang, justp ointing out the apparent contradiction
<zid>
did that mean that 20 seconds after the paper, they had a huge drive and reduced server load by 1%? no.
<heat>
mjg, why are you assuming there's a contradiction?
<mjg>
the claim is changes got eployed and resulted in saforementioned savings
<zid>
all my googler friends spend all day writing python and shit to run random queries on their giant datasets that have optimized *backends* written in C or whatever
<mjg>
heat: i'm saying worrying about icache does not mesh with deploying several different *static* binaries
<heat>
static linking does result in smaller binaries
<moon-child>
I guarantee you better gc and better codegen would make a way bigger difference than dynamic linking
<mjg>
i'm not saying it would not
<mjg>
clearly the results they got were NOT from go workload
<moon-child>
afaik google perf sensitive stuff is all c++ anyway
<mjg>
... as they were patching libc or replacing parts of it
<heat>
you are assuming that having multiple binaries that dynamically link the same .so does result in good TLB + icache sharing
<moon-child>
go is good-enough performance for fungible devs
<mjg>
moon-child: 's what i'm saying
<zid>
moon-child: yup, it's the "products" that are in the fancy languages
<zid>
that random beta they will shut down in 4 weeks
<mjg>
heat: i am, yes
<heat>
do you have any data to back this up?
<zid>
before anybody tries to optimize it and sell it as a real product :p
<mjg>
heat: well it results in some degree of sharing by definition, so to speak. how much of a difference does it make -- who knows
<bslsk05>
killedbygoogle.com: Google Graveyard - Killed by Google
<mjg>
heat: they claim replacing glibc memcmp which wsa 6 kb in size(!) with something smaller gave them a win
<zid>
Their actual core business isn't
<mjg>
so
<heat>
mjg, yes but how much sharing and how does that compare with the benefits of static linking
<heat>
and how much sharing /on their workload/
<mjg>
so for example memcmp is used a lot by most code and in this cae it would be fully shared
<heat>
yeah and conventionally it also requires a freaking indirect call
<mjg>
ye there is overhead from it for sure
<heat>
and then things are more spread out in memory, so your TLB hit rate probably won't be as good
<mjg>
something like glibc could be backed by a huge page
<heat>
etc. i don't think it's as clear cut as "gogle stopid"
<mjg>
and it is used a lot
<zid>
google too big to care
* moon-child
still doesn't understand why you can't patch the plt to do a direct jump
<mjg>
they literally wrote a fucking paper claiming they do care
<heat>
google is not too big to care
<mjg>
in fact 2
<moon-child>
I've been told there's concurrency issues, but cross-modification is sound if aligned
<mjg>
that i know of
<zid>
'they' = random engineer in a few hours for his next eval to look good
<heat>
what do you think the kernel teams do?
<mjg>
ye i admit for all i know the paper got burried and realities of production are like they used to be
<heat>
eat rocks?
<zid>
googl engineers spit out thousands of papers that go nowhere a year I'm sure
<mjg>
:]
<heat>
getting a 1% win is a fucking win and a half
<zid>
800 of them are w3c standards that they implemented in chrome 3 years ago at least
<mjg>
btw is there a problem making go use llvm as a backend/
<mjg>
to actually optimize the code
<moon-child>
there's a 'gccgo'
<heat>
in theory you have gcgo
<heat>
the problem is that it sucks
<moon-child>
but I would guess gcc and llvm are bad at emitting gc barriers and such like
<moon-child>
(llvm in theory has an interface for it, but it seems to suck)
<mjg>
g has llvm devs
<mjg>
probably easier to sort out than to write their own optimizer
<moon-child>
wasn't go originally a 'let's hire og unix luminaries and let them do whatever because we can' side project that then turned into an actual thing
<mjg>
it was written by people who were at g for years as is
<mjg>
e.g., rob pike
<moon-child>
probably they want to keep their own code generator for political reasons
<mjg>
ye i would expect there is something non-tech at play here
bauen1 has joined #osdev
<mjg>
the funniest thing about is that the guy claims G people are just programmers, not researches. incapable of understanding of a brililant language
<bslsk05>
zchee.github.io: Plan9 - Go Programming Language Wiki
<CompanionCube>
better source: 'The assembler is based on the input style of the Plan 9 assemblers, which is documented in detail elsewhere. If you plan to write assembly language, you should read that document although much of it is Plan 9-specific. The current document provides a summary of the syntax and the differences with what is explained in that document, and describes the peculiarities that apply when writing
<bslsk05>
go.dev: A Quick Guide to Go's Assembler - The Go Programming Language
<CompanionCube>
also https://docs.google.com/document/u/0/d/1P3BLR31VA8cvLJLfMibSuTdwTuF7WWLux71CYD0eeD8/mobilebasic, 'The “gc” Go toolchain is derived from the Plan 9 compiler toolchain. The assemblers, C compilers, and linkers are adopted essentially unchanged, and the Go compilers (in cmd/gc, cmd/5g, cmd/6g, and cmd/8g) are new C programs that fit into the toolchain.' (of course rewritten for go 1.4 as the documenr
<CompanionCube>
describes'
<bslsk05>
docs.google.com: Go 1.3+ Compiler Overhaul
<mjg>
better show the me essay where he makes the problem with understanding claim
* CompanionCube
doesn't have a link, but heard the same story in the past and never watched the video so
<mjg>
maybe it came rom the video
<mjg>
it is about 9 years now
<mjg>
but ye, i would not be surprised if he expressed this numerous times by thatp oint