<veltas>
Was thinking about this idea of namespaces and this is what I came up with, not sure how useful it is
<veltas>
You can probably improve this with recognisers, but I don't know what kind of support they have
mark4 has quit [Remote host closed the connection]
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
mark4 has joined #forth
<mark4>
having to totally reinstall linux on this laptop
sts-q has quit [Ping timeout: 240 seconds]
sts-q has joined #forth
Keshl has joined #forth
gravicappa has joined #forth
dave0 has joined #forth
nihilazo has quit [Ping timeout: 252 seconds]
proteus-guy has joined #forth
dave0 has quit [Quit: dave's not here]
proteusguy has quit [Remote host closed the connection]
<inode>
nice concept veltas
<neuro_sys>
Currently I'm "okay" with redefining same words across different files, but it's not safe, i.e. it leads to bugs if it's mixed up. But I think when I start using vocabularies or wordlists there won't be a problem? I still haven't looked much into them. Maybe even they are not a solution for hiding words across different files.
<veltas>
mark4: Why?
<neuro_sys>
Ah, finally started using the return stack and it basically eliminated the need for variables in many places without making the code any harder to read.
<veltas>
Nice
<veltas>
I just use return stack where it makes code simpler, I know some people try to avoid it entirely
<veltas>
I think they're concerned about messing up backtraces or optimisation
<neuro_sys>
Nice, I'll have a look. The use of CREATE...DOES> is still something I haven't looked into.
<inode>
i've been playing with it a bit
<inode>
the only thing i've noticed is that LOCAL: X in interpret mode doesn't give me 5 :)
<veltas>
inode: No of course not :P
<veltas>
Well I could fix that probably but I don't like state-aware stuff
<inode>
just for fun i went down a rabbit hole of adding LOCAL:: as a NS-PREFIX2 to see what would happen, but i ended up factoring out NS-VOCAB's DOES> phrase into a PUSH-WORDLIST and then realised i needed a ?PUSH-WORDLIST to detect if the wl was already at the top of the search order, so i stopped
<veltas>
If I had a normal module I would probably define two namespaces, one named after the module and one in the module called LOCAL
<inode>
so LOCAL:: did end up working, and worked in place of LOCAL: too, but i didn't like that any words out of the namespace were still accessable as, LOCAL:: "name", because the DOES> phrase was something like @ ?PUSH-WORDLIST PARSE-NAME EVALUATE
<veltas>
Oh PUSH-WORDLIST adds a wordlist to search order?
<inode>
heh only if you make it yourself
<veltas>
I made a word once called FIRST-ORDER , thought I was being pretty funny too :P
<veltas>
inode: I have updated the files to make the prefix state-aware
<veltas>
i.e. you can see in example I can do LOCAL: X at interpreter
<inode>
ah i see your STATE @ IF COMPILE, EXIT THEN now
<veltas>
I want to write a bigger example to demonstrate the power of this fully armed and operational library
<veltas>
inode: I don't fully understand what you're saying but can I guess that you've made it so you can just type "LOCAL" to push its wordlist onto search order?
<veltas>
So you just use e.g. LOCAL .... PREVIOUS ?
<veltas>
inode: Line 12, why not just SET-ORDER RDROP
<inode>
didn't think of that, just wanted to get rid of what was there already
<veltas>
Okay inode I see what you're doing but I don't want to find stuff that's not in the namespace when I use the prefix
<veltas>
I would consider that a defect
<inode>
that's EXACLTY why i said: 'i didn't like that any words out of the namespace were still accessable as, LOCAL:: "name","'
<veltas>
Oh right
<veltas>
Sorry I think I switch off when I get confused sometimes :P
<veltas>
I want this to act like an alternative of naming your words with an actual prefix in the name, that lets you just use the name with the right 'scope'
<inode>
no problem, i have the same problem :)
<veltas>
You didn't suggest it but I actually like the idea that it pushes the wordlist
<veltas>
I've changed it to do that so I can just use "LOCAL ... PREVIOUS" to use the namespace without prefix
<veltas>
And pushed
<veltas>
the update to git
dave0 has joined #forth
<veltas>
inode: It's time to upgrade your gforth
<inode>
is there a 0.7.4 or 0.8 finally available?
<inode>
i've seen the many daily snapshots of 0.7.9
<inode>
but afaik 0.7.3 (now almost 7 years old) is the last "stable" release?
<neuro_sys>
Hmm the Forth for Amstrad CPC doesn't have the word VALUE. I'll try to define it myself, but asking here first.
<veltas>
"PForth began as a JSR threaded 68000 Forth called HForth that was used to support HMSL, the Hierarchical Music Specification Language. HMSL was a music experimentation language developed by Phil Burk, Larry Polansky and David Rosenboom while working at the Mills College Center for Contemporary Music."
<veltas>
"Phil moved from Mills to the 3DO Company where he ported the Forth kernel to 'C'. It was used extensively at 3DO as a tool for verifying ASIC design and for bringing up new hardware platforms. At 3DO, the Forth had to run on many systems including SUN, SGI, Macintosh, PC, Amiga, the 3DO ARM based Opera system, and the 3DO PowerPC based M2 system."
<inode>
does pForth have something like CODE for writing words in assembly?
<veltas>
I don't think so, but it has the ability to use link external C functions easily, so you can get assembly in there too
<veltas>
It's an acceptable tradeoff, I think C forths are legitimate, I am incline to write one myself (pForth lacks a lot of core Forth features like doubles)
<inode>
i agree, they have their place. i'm not very fond of gforth's c-library/c-function approach to C FFI though
<veltas>
I'm not fond of a lot in gforth other than it exists and has successfully implemented most of Forth200x
<veltas>
And also it has very good performance
<inode>
i wanted to make syscalls lately (for SYS{_read,_write,_close,_socket,_connect,...}) and instead of calling them via a C library i felt it made more sense to call them directly instead, as gforth doesn't seem to expose syscall(2)
dave0 has quit [Quit: dave's not here]
<veltas>
I think you can call them directly with syscall, you'd have to look up how to call external C functions in gforth
<veltas>
Well I'm not sure, I just know I don't like how it works in gforth, seems way too complicated
mint_ has joined #forth
mint_ is now known as mark4
nihilazo has joined #forth
gravicappa has joined #forth
cmtptr has quit [Quit: leaving]
cmtptr has joined #forth
mark4 has quit [Remote host closed the connection]
f-a has quit [Ping timeout: 240 seconds]
<neuro_sys>
Upgrading gforth to 0.7.9 somehow broke some calculations and numbers are all wrong now, but it doesn't crash. I'm curious to find out what strange assumption my code was making. :P It must be the hastily written fixed point math.
f-a has joined #forth
<veltas>
Hmmm that's annoying
<veltas>
Hopefully you can track it down
mint_ has joined #forth
mint_ is now known as mark4
mark4 has quit [Remote host closed the connection]
gravicappa has quit [Ping timeout: 246 seconds]
gravicappa has joined #forth
MrMobius has quit [Ping timeout: 245 seconds]
MrMobius has joined #forth
<cmtptr>
maybe right-shifting signed values
Zarutian_HTC has joined #forth
nihilazo has quit [Ping timeout: 240 seconds]
nihilazo has joined #forth
f-a has quit [Remote host closed the connection]
jess has quit []
f-a has joined #forth
<siraben>
Why fixed point? Doesn't that severely limit the range of values you can express?
<siraben>
FP, if you are aware of ulps and representation and approximation, seems quite predictable.
f-a has quit [Ping timeout: 240 seconds]
f-a has joined #forth
<inode>
are there any standard means of detecting endianness? something besides storing a multi-byte value and then fetching the first byte at the storage location to check whether it's the most significant or least significant byte maybe?
<inode>
s/a multi-byte value/an integer value that is greater than 256/
<inode>
^ 255 :(
<inode>
also i'm not concerned about mixed endianness
<cmtptr>
what's wrong with that method?
<cmtptr>
siraben, fixed point can express more values in the same number of bits
<siraben>
cmtptr: I was referring to range
<inode>
cmtptr: it works, but i'm wondering if there's any standard word i've missed that would do it for me instead
<siraben>
you have representatives evenly on a range of the reals, sure, but I like that in FP the representatives get spaces out more as you go away from 0
<siraben>
i'd need to study numerical analysis to really judge, I guess
<cmtptr>
siraben, in some applications that is undesirable
<cmtptr>
in fact (we've had this discussion a few times in this channel now), i actually can't think of any application where that would be desirable
<cmtptr>
but anyway, usually the reason to use fixed-point is because the platform doesn't have an fpu or fixed point is just faster
<siraben>
cmtptr: undesirable to lose accuracy as you go further out?
<cmtptr>
yeah
<inode>
otherwise to be endianness-agnostic i guess i need to generate integer values in network-byte order (big endian) so maybe i should slice off bytes from most significant (assuming 32 bits, number 24 RSHIFT $FF AND) to least significant (number $FF AND) and write them out to variable storage in that order
<cmtptr>
inode, you know the endianness of your target platform at compile time. deliver the appropriate implementation then
<inode>
cmtptr: it's to implement htons/htonl in forth, i'm hoping to avoid detecting endianness if possible
f-a has left #forth [#forth]
<cmtptr>
i know, and i'm saying you don't need to detect endianness because you know what platform you're targetting
<cmtptr>
c htons/htonl don't detect at runtime
<inode>
well let's say i write a port number out to a field that equates to sockaddr_in.sin_port, if i'm on a little endian system like i386 i need to reverse the byte order for the kernel to accept it when i pass it to SYS_connect - if i'm on a big endian system no conversion is necessary - if i write a word to retrieve each byt eof the integer from most to least significant and write it in that order to the
<inode>
appropriate address, it'll work on both systems without being explicitly told which order is required
<cmtptr>
first, yes i know what hton does. second, if you're just passing a value to the kernel, then that's in memory and you can write it in native order and the kernel will read it in native order - you only need to care about endianness when you're putting values on some medium that might be read by another cpu, like on disk or the network. third, you still haven't acknowledged the fact that in c, hton does
<cmtptr>
not detect endianness
<inode>
i'm calling total bullshit on that
<inode>
on a little endian system, pass the value of sin_port or sin_addr in the native byte order
<inode>
it doesn't work
<inode>
if this was the case, you wouldn't need hton{s,l} at all
<cmtptr>
hton is not for talking to your kernel
<cmtptr>
sorry you're confused about that
<inode>
i'm passing values directly to a sycall
<inode>
syscall*
<inode>
i HAVE to generate sockaddr_in appropriately
<inode>
i've literally just confirmed if i don't use network byte order then it doesn't work
<phadthai>
from htons BSD man page:
<phadthai>
On machines which have a byte order which is the same as the network
<phadthai>
order, these routines are defined as macros that expand to the value of
<phadthai>
their argument.
<phadthai>
so a noop on big-endian
<cmtptr>
sorry, connect syscall does expect for the sin_port field to be in network order. i forgot about that
<cmtptr>
guessing because historically the unix kernel would just blindly copy it into a buffer without any manipulation, and so the abi just stuck
<cmtptr>
it's not because the kernel reads memory in network order (in fact if you look at the linux implementation of connect you'll see that when it needs to do something with the port number, it turns it back into host order with ntoh)
gravicappa has quit [Ping timeout: 260 seconds]
<inode>
and sorry for that sort of response, i do agree that you usually don't have to care about adjusting the byte order and agreed about libc hton*() doing-the-right thing at run time because of how they were expanded by the preprocessor
<cmtptr>
now let's kiss and make up
<inode>
heh
<Zarutian_HTC>
tell me something. If miss aligned cell fetching causes delay or traps then why have byte addressed memory?
<veltas>
To save memory storing stuff that isn't a word?
f-a has joined #forth
<veltas>
You could make all bytes bitfields and that's effectively how they act in the way CPUs are built today, with special instructions to handle "8-bit aligned bitfields" we call bytes
<veltas>
And the addresses may as well be for a word offset rather than a byte offset
<veltas>
It's all conventiob
<veltas>
convention*
<Zarutian_HTC>
there was an isa that cheaply extracted any sized bitfield from any offset into a cell
<veltas>
PowerPC can do it nicely
<veltas>
I'm sure others can too
f-a has left #forth [#forth]
<veltas>
It's quite arbitrary, it's all convention. Once upon a time we really did care about bytes or bytes were all that could be loaded at a time. These days the cache can be designed to optimise for any size and RAM sends like 64 bytes at a time
<Zarutian_HTC>
ram is the new disk while cache is the new wram
<veltas>
We just have way more levels than we used to
<veltas>
We used to have exactly 3: register, RAM, storage. Now registers aren't even real, even RISC CPUs have multiple copies of each register for pipelining. X86 is secretly using a different arch under the hood and optimising your code
<Zarutian_HTC>
one isa feature I have not seen in todays isas is the tlb cam being mapped into kernel memory address space
<veltas>
Whether it's in memory or accessed via an SPR is kind of irrelevant IMO
<Zarutian_HTC>
was on some sort of m68k variant
<veltas>
That's probably because the TLB was on a separate chip
<Zarutian_HTC>
it meant that process switching did not incurr the usual tlb flush and page table rewalk penalty
<Zarutian_HTC>
the process control block got a big bigger though
<Zarutian_HTC>
upon process context switch the tlb state got blitted out and the next process tlb got blitted in
<Zarutian_HTC>
the blitter was used as an dma accellerator
tech_exorcist has quit [Remote host closed the connection]
tech_exorcist has joined #forth
<veltas>
Somehow I resisted getting involved in the fixed/float argument today
<veltas>
Whatever floats your boat :P
<veltas>
Just make sure it's fixed before you release :P