log☇︎
221900+ entries in 0.129s
trinque: see the conferences, "social coding", hackathons, etc
trinque: nah, the idea that these guys are using this as a substitute for healthy human interaction is spot on.
asciilifeform: maggots dun have plans, or objectives, they simply eat.
mircea_popescu: it's quite evident from their gestalt they're coding with flashlight under the covers.
mircea_popescu: incidentally, if the various dreppers etcs actually had any friends, the whole rot wouldn't exist in the first place.
mircea_popescu: good brothel = many whores, small building. not vice-versa. that's called "beachfront property".
mircea_popescu: large teams, small programs. not the other fucking way around.
mircea_popescu: but this may just be me.
mircea_popescu: asciilifeform no i liked that part.
mircea_popescu: i must say candi_lustt made it obvious lisp is workable development. way the fuck faster than figuring out which stdio to include and dumb shit like that
mircea_popescu: my model is... well, aptly put, stick shift. ie, even if dudes wanna bitch about lisp, because "c is faster", the above STILL APPLIES
mircea_popescu: yeah and then interpreter bitches if wrong types, so it catches size issues by default.
asciilifeform: if cpu wants to move, add, subtract, etc. a bitstring, it has a length glued to it, and a type (that indicates, among other things, what it means to 'add' it, say), also glued to it.
asciilifeform: on a proper lispmtronic comp, there is no juggling of 'pointers' or any other naked, unannotated bitstrings.
mircea_popescu: and literally &p:sizeof(p*) calls throughout all c, none of this current bs.
mircea_popescu: anyway. all pointer references to read must be offset:size or no dice ; all pointer references to write may be offset, and will write mod size ; all pointer allocation specifies size and receives offset.
asciilifeform: it did, though not in the peculiar 'stick shift' way described by mircea_popescu earlier
mircea_popescu: i suppose its tagged memory model does pretty much a superclass of the above
mircea_popescu: if it actually does that.
mircea_popescu: i don't want the functionality exposed.
asciilifeform: on a proper lispm (definitionally) it is done by the iron.
mircea_popescu: yes but that's an os.
asciilifeform: mircea_popescu: in sane programming system (e.g., lisps) nobody gets to point to 'memory address'. they point to an item that necessarily and unseparably carries not only address (not visible to or alterable by the operator, normally) but also a type and -- when the thing is >1 machine word in size -- a size.
mircea_popescu: if you provide buffer size, and it is the correct buffer size for offset, you can read that many bits.
mircea_popescu: if you fail to provide the buffer size, cpu reads 0 bits from address specified.
mircea_popescu: that doesn't mean the cpu die must be cast in such a way as to allow anyone else to do it.
asciilifeform: but if you had something clever in mind, around this, i'm all ears
asciilifeform: mircea_popescu: for so long as memory is sold as a dumb capacitor grid, cpu can necessarily address all of it (that is, all of the connected ones)
mircea_popescu: i want the cpu to not be physically capable of addressing it.
asciilifeform: the simplest way to do this using current off-the-shelf hardware is to not expose the pointers.
mircea_popescu: it must not be possible to read from x unless you correctly specify the ring size.
mircea_popescu: ie "i want to read from x onwards".
mircea_popescu: yah, but i want this quite exactly, for it to not be POSSIBLE for memory to be addressed as it currently is.
asciilifeform: how cpu physically moves the bits, is quite separate question from what operator thinks about.
mircea_popescu: cpu can only address memory if the correct size (0a) is provided for 0x88faf0.
mircea_popescu: cpu can not address memory in the sense of "from here to eternity".
mircea_popescu: not necessarily operator, but also none of the current straight on addressing bs.
mircea_popescu: at some point raw pointers must be given to someone
asciilifeform: holy fuq why would you give the operator raw pointers.
mircea_popescu: you'll be left with the last 10
mircea_popescu: your pointer is 0x88faf0:0a and god help you, if you wish to write 500 bytes in there all the better.
mircea_popescu: yep. but cpu-enforced, all memory allocation is that.
asciilifeform: mircea_popescu: ada's 'modular types' come to mind
asciilifeform: (instead of 1 model of computation, you now have 3 -- that you know about. plus others, unwanted, resulting from interactions b/w the 3.)
asciilifeform: at the cost of destroying whatever conceptual integrity machine might otherwise have.
asciilifeform: they make it possible to actually do any work on von neumann monstrosity.
asciilifeform: interrupts, dma, are relics from dark age when there was 1 cpu and it cost most of what the machine cost.
asciilifeform: is how i got there.
a111: Logged on 2017-01-19 17:49 asciilifeform: the two major caltrops re 'iron lisps on x86' are 1) interrupts 2) dma
mircea_popescu: http://btcbase.org/log/2017-01-19#1605218 << actually non-interrupt / non-dma (and possibly tagged ram) is about the reason to make own fpga cpu ☝︎
asciilifeform: (yet unpublished) 'p' is a 'bytecode' system -- all ops are 1 byte long, and take no operands, and all bytes are valid ops.
asciilifeform: name 'bytecode' simply came about because making the opcodes 1 octet long is convenient
asciilifeform: e.g., perl, python, tinyscheme, many forths
asciilifeform: well ~all interpreted programming languages use 'bytecode' or some variant (i.e. emulator for fictional cpu that fits the task)
mircea_popescu: yes but started (at least i think) as vops.
asciilifeform: mircea_popescu: nah, 'jets' were a terrifying crackpottery where he promised to 'recognize algorithms' and 'transparently' substitute in optimized/c-tronic routines
a111: Logged on 2017-01-19 17:40 asciilifeform: or is it 'bytecode' a la tinyscheme?
mircea_popescu: http://btcbase.org/log/2017-01-19#1605206 << i always thought that's what yarvin was john smithing with his "jets" ☝︎
asciilifeform: trinque: i must note: just because asciilifeform barfed, does not mean that a clean solution to the problem cannot exist. only that he did not find one.
a111: Logged on 2017-01-19 17:31 asciilifeform: seems like a fully-musltronic, work-ready linux is possible, then.
mircea_popescu: http://btcbase.org/log/2017-01-19#1605192 << this wouldn't hurt anything. ☝︎
trinque: ah ok, thoughts were connected
asciilifeform: trinque: tldr: interrupts and dma.
trinque quite interested to hear why asciilifeform barfed
thestringpuller: that trailing slash >> http://btcbase.org/log-search?q=http%3A%2F%2Fvisual6502.org
thestringpuller: http://btcbase.org/log-search?q=http%3A%2F%2Fvisual6502.org%2F << that one
asciilifeform: thestringpuller: linked in the logs.
asciilifeform: sorta what asciilifeform tried to do (then barfed.)
asciilifeform: the two major caltrops re 'iron lisps on x86' are 1) interrupts 2) dma ☟︎
phf: you could maybe put cmucl's interpreter vm into l0, have vops as operations that you need but that you don't have in a vm (simd, floating point)
phf: actually it's all a lot more clearer when you read the early cmucl papers. the mess grew in unix user space..
asciilifeform: not necessarily, though it is one way of achieving this.
asciilifeform: (this imho is quite sorry state, you oughta be able to go from the executable TO the lisp representation without ANY info loss)
phf: well, that's not the right term to use. depending on a vop it either jmps, calls or inlines
phf: it's sort of "writing assembly with sexp", but really it's an abstraction layer for what used to be microcoding
asciilifeform: or is it 'bytecode' a la tinyscheme? ☟︎
phf: so cmucl introduced this whole idea of vops (virtual operation)
asciilifeform: then thing has a chance of working correctly.
asciilifeform: also (and iirc i discussed this on my www at one point) the correct approach is to ditch the native compiler, in favour of the interpreter, hand-compiled to fit in L0 cache ☟︎
asciilifeform: imho this is one of those things that will have to be demolished ~100% and rebuilt from scratch , for any reasonable 'metallization'
phf: there's some strategy in building multithreading in a lisp that all the commercial lisps share with cmucl and that's different from sbcl, but i'm not quite sure what it is yet
phf: re cmucl threads i think that it doesn't always preempt correctly. like it has explicit yield, which you don't always have to call, but it being there implies. also hunchentoot wasn't working right without putting a yield somewhere in the scheduler. it's all very vague, because i've not spend any time looking at it
asciilifeform: (then perhaps some luxuries, e.g., 'midnight'. then x11 and ratpoison. is pretty much all.
phf: well, stali has a musltronic pdf reader and web (they have their own wrapper around webkit, called st i believe, which is literally just a frame with addressbar)
asciilifeform: emacs, gcc4.9+gnat, build tools, trb, kernel.
asciilifeform: seems like a fully-musltronic, work-ready linux is possible, then. ☟︎
phf: no, i'm not that far in the stack to tackle threading. because of goals, if i do, or once i do rather, i'll just work on making them better green threads, rather than native.
asciilifeform: also it does seem to insist on dynamic linking.
asciilifeform: trinque: you tested, worx? also on x11 ?
asciilifeform: ty trinque !
a111: Logged on 2017-01-19 17:16 asciilifeform: !~later tell trinque re: http://btcbase.org/log/2017-01-19#1605086 >> plz consider posting recipe for musltronic emacs build! i promise to test.
trinque: http://btcbase.org/log/2017-01-19#1605148 << https://cgit.gentoo.org/proj/musl.git/tree/app-editors/emacs/files << without claims to the sanity of anything done ☝︎
asciilifeform: as in, 'the locking system is defective in yet-undiscovered way, proggy fandangoes over own toes'
phf: well, you were right, it's the lack of threads. you can't build for cmucl green threads like it's native.
asciilifeform: phf: did you ever expand on why your gadget crashed daily when it sat on top of cmucl ?
asciilifeform: instead ought to simply have 1 permanently-running instance of the runtime per cpu core
asciilifeform: incidentally imho traditional unix-style scheduler is not appropriate for 'x86 iron lisps'
phf: cmucl is basically a very straightforward lisp machine port, so there's less unixisms built in. sbcl is modernized for unix, but with corresponding tradeoffs
asciilifeform: traditional headaches turn to wins, the fewer 'native xyz...' the better, for iron.
asciilifeform can picture this.