<m_mans>
Regenaxer: how much time can it take to replace variable length arrays with alloca in PicoLisp32?
<m_mans>
is it possible in general (I hope)?
<tankfeeder>
he answered : i will not do it
<tankfeeder>
when discussed clang migration
<tankfeeder>
correct question: how much $$$?
<tankfeeder>
:)
<m_mans>
tankfeeder: no, I don't want to ask him to do that. I understand that Picolisp32 is obsolete. I want to understand how much work it could take if we do that
<Regenaxer>
Good morning m_mans, tankfeeder!
<tankfeeder>
o/
<Regenaxer>
I'm not sure at the moment, at how many places it occurs, and how exactly to solve it
<Regenaxer>
Also, what alloca() involves internally, ie. to what code it compiles
<m_mans>
all this because of Elbrus CPU. Currently we doubt that we can write assembly for Elbrus. VLIW architecture is very different. Also we still have not much documentation (it's closed)
<Regenaxer>
I see, nasty
<m_mans>
Elbrus C compiler *does* much work of Intel microcode
<Regenaxer>
But it has 64-bit pointers?
<m_mans>
it has much more than 64 it seems
<Regenaxer>
ok, it implements the microcode directly in long words it seems
<Regenaxer>
What pil64 is interested in is only the pointer size
<m_mans>
and it has 6 Functional Units (FU) for every core, they are not equal, so every 'long instruction' has instructions for every FU
<Regenaxer>
The best would be to port pil64 of course
<m_mans>
so if one want to manually write efficient asm code for Elbrus, he must instruct all 6 FU what to do in the clock cycle
<Regenaxer>
Sounds very powerful
<aw->
hmmm... m_mans if you can't write assembly for that CPU, how can Regenaxer port pil64 to it?
<m_mans>
aw-: that's why I'm asking details about pil32
<Regenaxer>
The question was more about alloca() for pil32 I think
<m_mans>
T
<Regenaxer>
:)
<Regenaxer>
But if the pointer size is 64 bits, pil32 makes trouble too
<aw->
Regenaxer: unrelated question, how can I perform one's complement of a binary number in PicoLisp?
<m_mans>
256 registers
<m_mans>
seems that registers are unusual
<Regenaxer>
unusual in which sense?
<m_mans>
btw my colleague said that C program can be compiled in 32bit mode, no problem with that
<Regenaxer>
ok
<Regenaxer>
But pil32 has other limitations too. How about 'emu'? It does not need alloca()
<m_mans>
unusual - there are some "windows" to restrict access of current code to some part of the whole "register file"
rob_w has joined #picolisp
<m_mans>
I didn't study all this yet :)
<m_mans>
emu works, but it's slow.
<Regenaxer>
right
<Regenaxer>
brb
Regenaxer has left #picolisp [#picolisp]
Regenaxer has joined #picolisp
yumaikas|away is now known as yumaikas
beneroth has joined #picolisp
<beneroth>
hi all
<Regenaxer>
Hi beneroth!
<beneroth>
hi Regenaxer :)
<aw->
hi beneroth
<beneroth>
yo aw- :)
<beneroth>
in case you guys haven't heard it: curl has a security issue (when server answer with redirect, it sends the same headers to new location - including basic auth header to new location)
<beneroth>
upstream patch is available, but debian and ubuntu are not packaged yet
<aw->
oh wow
<aw->
that's quite a fail
<beneroth>
also, clamav appears to have a serious code execution flaw (parser bug)
<beneroth>
well multiple
<beneroth>
dunno how the package situation is there. I didn't get any updates for it yet, but I only use it manually.
<beneroth>
aw-, apparently the flaw in curl was present from the very first version on. overlooked all this years.
<aw->
haha
<aw->
well..
<beneroth>
yeah...
<aw->
it's not a *huge* issue actually
<beneroth>
T. unless it pwns you. but yeah
<aw->
no?
<aw->
curl requests are not like browser sessions
<beneroth>
T. the server had to issue the redirect first.
<aw->
i can't imagine making an auth'd curl request to a site, and then have it redirect me to some random site that steals my auth data
<aw->
exactly
<beneroth>
should not be a problem when using TLS
<aw->
yes that too
<beneroth>
pure HTTP -> you use curl on one of those wlans who like to redirect you to a terms&condition page -> ups
<aw->
well... we all know not to connect to those, right?
<beneroth>
haha T
<aw->
unencrypted, unauthenticated, "free wifi" open access points.. yeah no thanks
<aw->
i think that's called "captive portal" btw
<aw->
you can disable that
<beneroth>
we (in this channel) probably all know this. but no chance to expect that from average people. (thought they're also not the target audience for curl.)
<aw->
hahaha
<beneroth>
EU laws (CH too, agreed by a public vote because population didn't get it) require that you as an internet provider have to identify your users. in CH the law is unclear about big provider vs. barber with free wifi, it tries kinda to distinct between them but doesn't really
<beneroth>
hence those captive portals are widespread and will probably be used even more in the near future
<beneroth>
how is the situation in Japan on that?
<aw->
wow that's crazy
<aw->
actually, Japan has an identical policy for internet providers
<aw->
yes those captive portals are on many free wifi spots here.. but I know a bunch of cafes which provide free wifi and don't have those portals
<aw->
hmmm wait let me think
<aw->
if i recall, the free public wifi spots only require an email address
<aw->
unlike South Korea which requires you to use your national ID number
<aw->
Japan might get to that point eventually, if they manage to get everyone enrolled in the "national ID" system (I'm not, I refused it)
<aw->
but for home/mobile wifi, as well as for web hosting / colocation, you need to provide personally identifying information
<beneroth>
the net becomes tighter
orivej has joined #picolisp
<aw->
indeed
mtsd has joined #picolisp
aw- has quit [Quit: Leaving.]
aw- has joined #picolisp
aw- has quit [Client Quit]
mtsd has quit [Ping timeout: 260 seconds]
rob_w has quit [Quit: Leaving]
rob_w has joined #picolisp
karswell has quit [Remote host closed the connection]
karswell has joined #picolisp
<tankfeeder>
beneroth: where you read about curl and clamav?