looks like linux changed the device tree names for
the memory node:
4b17654f51 (diff-ac03c9402b807c11d42edc9e8d03dfc7)
this fixes the memory size detection with latest firmware
on raspberry pi4-b (4GB) for kenji.
with scroll-wheel scrolling, this case can happen with the
command window:
umbraticus → cinap: create fullscreen file buffer by right-clicking in cmd window
slookup() copies to symb, so use the symb[NSYMB] buffer directly
to declare type conversion functions and get rid of the arbitrary
sized local buffer. replace sprint() with snprint().
We used to treat all operators as right associative,
which means that we would evaluate them incorrecty.
For example, '2 - 1 + 1' would evaluate as '2 - (1 + 2)',
instead of '(2 - 1) + 1'.
This adds an assoc parameter to struct pri, and then uses
it to decide how to evaluate operators.
when pushing expressions in cpp, particularly complex ones could
overflow the stack and silently corrupt our data structures. add
checks when we push, and bump the stack size up.
for floating point operations, reuse the return register
on the right hand side if it has higher complex number
than the left hand side to conserve registers.
this makes the following code compile, that was previously
run out of floating point register:
float
f(float r[15])
{
return (r[0] + (r[1] * (r[2] + r[3] * (r[4] + r[5] * (r[6] + r[7] * (r[8] + r[9] * (r[10] + r[11] * (r[12] + r[13] * r[14]))))))));
}
the downside is that this produces extra move operations.
BurnZeZ reported this the other day. It seems like if we have
a pipeline that looks like:
fn foo{cat < <{echo hi}}
then the '<' will get merged in /env/'fn#foo'. This change
fixes pcmd to add a space. It looks to me like this is the
only token that can get merged this way by pcmd.
The previous patch to plumb non-whitespace segments was
confusing due to lack of visual feedback. This removes
the empty selecton plumb behavior, and instead makes
triple clicking work to get a plumbable selection.
when running ndb configuration, we might inherit the ipgw=
attribute from the ipnet pointing to our own ip address
(we are the default gateway). ignore such entries.
do not add default routes with gateway equal to our own
local (ip4) or link-local ip address (ipv6).
mysbrk() was only used in gethunk() and should not be
called by anyone, so dont export the symbol.
simplify gethunk() using brk().
double allocation size on each call until we reach
1000*NHUNK.
use signed long for nhunk as alignment rountin might
make it negative and handle that case.
for gethunk() to work, all allocators have to use it,
including allocations done by libc thru malloc(),
so the fake allocation functions are mandatory for
everyone.
to avoid duplication the code is moved to cc/compat
and prototypes provided in new cc/compat.h header.
the assemblers share gethunk() cc/macbody but are compiled
without compat.c, so calls such as getenv() trigger malloc()
which does its own sbrk() calls, breaking the continuity
of the hunk.
so this change needs another revision. until then, this is
backed out.
the compilers and linkers use ther own memory allocator.
free memory is between hunk and hunk+nhunk. allocation
works by checking if nhunk is bigger or equal to the
amount needed, and if not, repeatedly call gethunk()
until there is. after that, the allocated amount is added
from hunk and subtracted from nhunk by the user.
the problem was when the needed amount was bigger than
the default NHUNK size gethunk() allocates per call.
gethunk() would not actually grow nhunk, but instead
just set hunk and nhunk variables to the last allocated
block. this resulted in a infinite loop of calls to
gethunk() until sbrk() would hit the maximum size for
the BSS segment.
this change makes gethunk() actually grow the hunk space,
increasing nhunk, and only updating hunk when nhunk was
previously zero. we assume that mysbrk() retuns increasing
addresses and that the space between the previous hunk+nhunk
and the new block base returned by mysbrk() is usable.
the real problem is that gethunk() does not grow the allocation
but just allocates a new hunk, so repeated calls to gethunk()
wont make nhunk grow to satisfy the allocation.
this will be fixed in a upcoming commit.
