Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC| has joined #forth
iyzsong has quit [Read error: Connection reset by peer]
TCZ has quit [Quit: Leaving]
reepca` has quit [Read error: Connection reset by peer]
reepca` has joined #forth
Zarutian_HTC| has quit [Ping timeout: 260 seconds]
kori has joined #forth
kori has quit [Changing host]
kori has joined #forth
Zarutian_HTC has joined #forth
merkc0 has joined #forth
WickedShell has joined #forth
<veltas>
I'm after a conventional name or recommendation for VARIABLE that takes an initial value
<veltas>
i.e. you'd do 0 INIT-VARIABLE COUNTER instead of CREATE COUNTER 0 , or VARIABLE COUNTER 0 COUNTER !
jsoft has quit [Ping timeout: 272 seconds]
merkc0 has quit [Ping timeout: 246 seconds]
rdrop-exit has joined #forth
<rdrop-exit>
veltas, FigForth's VARIABLE took an initialization parameter, so you'd do 0 VARIABLE myvar
<rdrop-exit>
Some Forths initialize their VARIABLEs to 0
<rdrop-exit>
I can't recall another common name for a variable that takes a initialization parameter, I think most people just use CREATE
<veltas>
Hmm I think CREATE is the way to go
<rdrop-exit>
My variables take a parameter, but it's for size and alignment, e.g.
<rdrop-exit>
32-bit variable myvar
<rdrop-exit>
cell variable my-other-var
<rdrop-exit>
for initialization I use a non-standard ALIGNED ( alignment <name> -- )
<rdrop-exit>
32-bit aligned myvar $ 12345678 32,
<rdrop-exit>
as my alternative to CREATE
<rdrop-exit>
it's past 2am, must sleep, goodnight :)
rdrop-exit has quit [Quit: Lost terminal]
antaoiseach has joined #forth
<antaoiseach>
hello folks!
<veltas>
Hello
antaoiseach has quit [Quit: leaving]
xek has quit [Ping timeout: 264 seconds]
dave0 has joined #forth
TCZ has joined #forth
dave0 has quit [Read error: Connection reset by peer]
dave0 has joined #forth
<crest>
tp: have you tried to use can bus instead of usb or rs232 for faster code upload?
<tp>
crest, no, usart is fast enough because the slowdown is in the compiling
<tp>
crest, my aim isnt the highest speed, it's the most useful IDE first, speed second
<crest>
but you stated repeatedly how important speed is to your workflow
<tp>
true, but thats after my IDE is dine
<tp>
done
<tp>
Ive always had access to ethernet on a M4
<tp>
and thats pretty fast, but I couldnt integrate it into my system
<crest>
ok ethernet is an order of magnitude faster again if you send in transmit large enough messages
<tp>
sure
<tp>
but it would be tons faster than the compiler
<crest>
unless your cpu is busy handling tcp/ip with one byte per packet
<tp>
so the speed of compiling is the limit on upload speed in my observation
<tp>
yeah
<tp>
overall, speed is vital to me
<crest>
even one line (at < 200) per packet isn't optimal for ethernet but one line per tcp packet should yield reasonable throughput
<tp>
but thats second in priority to a useful IDE
<crest>
after?
<tp>
so I get the IDE doing what I want, then maxamise the upload speed
kori has quit [Ping timeout: 260 seconds]
gravicappa has quit [Ping timeout: 258 seconds]
<veltas>
White-on-black or black-on-white
<veltas>
The eternal question
<tp>
the permanantly eternal question
<veltas>
I have a habit of switching fonts, sizes, strength and colours
<veltas>
But the most I've used is probably: Deja Vu Sans Mono, size 10, regular, white-on-black.
TCZ has quit [Quit: Leaving]
<veltas>
Actually I've got a real Forth question
<tp>
it's the unreal Forth questions I have problems with
<veltas>
What's a good way of handling structures with multiple cells without putting them in the dictionary or using ALLOCATE ?
<tp>
eww, way outside my pay grade
<veltas>
I have considered, for instance, trying to wrangle them on the data or return stacks and potentially passing around address to them *in the stack*
<veltas>
Having a separate stack somewhere to simplify handling them in words
<veltas>
Using the end of dictionary temporarily, similar to how the pad area works
<veltas>
ALLOCATE seems totally overkill/inefficient, but would greatly simplify usage
<crest>
veltas: just because the cells form structures doesn't make them less painful to manage on the stack unless everything is the same size
<crest>
if you use *just* such structures and normal cells you could reimplement all the stack jugglers
<crest>
but at that point what are you doing with the structs?
<veltas>
Nah you'd have to use ROLL PICK etc
<crest>
do you have to dynamically allocate them or could you just use allot instead of allocate?
<veltas>
Assume dynamic
<crest>
could you use here as a scratchpad without moving it?
<crest>
is their lifetime limited?
<crest>
because if you have variable sized structs with unknown lifetimes you just described the reason for malloc/allocate and free
<veltas>
Limited within the execution of a word
<crest>
in that case you could (ab-)use here as a pool allocator
<veltas>
I might be thinking too much like a C programmer, but in C you'd just put this on the stack. Using the heap or a pool allocator would be considered highly unnecessary
<veltas>
So I am wondering what kind of analogues we have in forth to give us that same amount of control, and not resort to a complicated allocator
<veltas>
I'm sure there is an answer, probably more than one answer
<crest>
in some forth systems you can pass negative numbers to allot
<veltas>
That would work sometimes, but if you're writing a word used as an immediate or within an immediate....
<crest>
it will explode in your face and result in a use after free
<veltas>
I already have ideas about how to implement this, anyway. But I also know I am not going to get the 'best' version of this down first time around
<crest>
how does your memory map look?
<veltas>
Well there are a lot of bytes
<crest>
oh really? :-P
<veltas>
What specifically are you asking about? Whether there's room for another special 'stack'?
<crest>
yes
<crest>
how large is your data stack anyway? could it even store all your structs?
<veltas>
Well I could fit that inside the dictionary, in a space preceding the words that would provide this feature
<crest>
would there be space on the return stack?
<veltas>
Currently both stacks are 120 cells or something like that
<crest>
and how many structs should your code be able to handle?
<veltas>
But structures don't need to be big, don't worry too much about that
<crest>
where's your free ram?
<crest>
is there any that's not reserved for the dictionary?
<veltas>
Yes there is a bit but don't worry too much where I find space, if there is a solution using space somewhere I will consider it
<veltas>
It's no difference where it is, unless it's near HERE
<crest>
if all your objects a similar sized use a slab allocator
<crest>
if you want to deallocate them all at once use a pool
<crest>
unless you have to append anything else to the dictionary you can use its free space
<crest>
to do this save the here value (on the data or return stack)
<crest>
allot your structs
<crest>
substract the new value from the old value to get the negative argument to allot
<crest>
unless your forth doesn't support negative allot
<veltas>
I am trying to keep option of supporting Forth 2012
<veltas>
So it does support negative ALLOT specifically
<crest>
in that case there is your stack big stack
<crest>
an other crazy idea is to do what the old macos classic did
<crest>
move objects to defragment the memory
<veltas>
Old Windows did that as well
<veltas>
Anyway no I am avoiding ALLOCATE, I will certainly avoid that lol
<crest>
and return double indidirect pointers instead of normal pointers
<veltas>
I tried this once on the spectrum and it had diminishing returns
<crest>
it didn't recommend it
<crest>
dealing with double indirect pointers and locking objects while there are direct pointers to them is fragile and infuriating
<crest>
and you had to guess the maximum number of allocations
<veltas>
Yep
rdrop-exit has joined #forth
<veltas>
rdrop-exit if you are willing I would be interested in your input on my question
<veltas>
It's in the log
<rdrop-exit>
hi veltas, sure but I'm half asleep not very coherent yet.
<rdrop-exit>
ok, I'll check the logs
<veltas>
But basically I want to know how to temporarily allocate structures during the execution of a word
<rdrop-exit>
use a scratch block
<veltas>
I am avoiding using ALLOCATE etc because it seems overkill, and e.g. in C you could just put it on the stack
<veltas>
What is a scratch block?
<rdrop-exit>
just a regular block that you reserve for temporary scratchpad use