<veltas>
cmtptr: I have thought about the static hash table thing too, I haven't gotten around to it but I want to get C to generate C code (i.e. C that is built before everything else, or with special #defines) to do stuff like that
<veltas>
Because who needs python?
<veltas>
Have you encountered gperf? It's a GNU tool for generating perfect hash functions/tables (i.e. so you can store everything in an array and do an unconditional hash lookup)
<MrMobius>
floatcomplex, could you reimplement it in forth then send it to lispmacs[work] to test on the avr setup?
<MrMobius>
floatcomplex, just guessing though it will be at least 5x slower than C and maybe 10x or more
<cmtptr>
veltas, yes i know about gperf, but i was thinking more about a hash table that's implemented by the program being compiled and can change at runtime
<cmtptr>
that was just one example case that i've encountered in the past
<veltas>
I do know exactly what you're talking about though
<floatcomplex>
MrMobius: i'm not the right person to do that and have it be a good indication for how fast the forth version could be
<floatcomplex>
i'll be the first to admit that
<veltas>
I think my idea is that if you build C code that generates e.g. files containing initializer lists to #include in your .c files, with the pre-generated state that you can't achieve otherwise, then you have the benefit of being able to depend on your existing headers/etc in that generation code
<veltas>
Rather than replicating definitions in e.g. Python
<veltas>
Something you get for free in Forth
<cmtptr>
i think forth does something special where it isn't a compiler, it's an interpreter and just so happens to define words which lay down compiled code or build data structures to compile them later. i've put a lot of thought into how to take that concept to something more c-like, but i think it's too fancy a problem for my tiny brain
<veltas>
Yep Forth makes my head hurt a lot too, it's a draw
<veltas>
It has changed how I write code in every other language
<MrMobius>
veltas, why not do that in Python though? arent you reading C source files in whether you do it in C or Python?
<MrMobius>
floatcomplex, just curious, what makes you wonder about the speed on an avr? lots of advantages to forth but you usually give up a lot of speed. kind of like other languages where you have a trade off
<veltas>
MrMobius: e.g. if I have tons of definitions, or I want to use my library functions to generate initial data, I don't want to maintain a Python version of all that
Zarutian_HTC has joined #forth
<MrMobius>
veltas, I guess it depends on what youre trying to do but what I meant was scanning in C source and making changes to it in Python
<MrMobius>
not rewriting an equivalent Python program to calculate things at compile time
<veltas>
I'm thinking of generating C source, rather than modifying it. I.e. generating the initial state of a struct. Trying to change source inline is a bit too messy for me, outside of preprocessor macros
<MrMobius>
ahh
remexre has quit [Ping timeout: 240 seconds]
remexre has joined #forth
Zarutian_HTC has quit [Remote host closed the connection]
WickedShell has quit [Remote host closed the connection]
dave0 has joined #forth
boru` has joined #forth
boru has quit [Disconnected by services]
boru` is now known as boru
tabemann has joined #forth
<siraben>
lispmacs[work]: I know where that paper is
<floatcomplex>
MrMobius: asking because i've done the fibonacci benchmark and it's kinda too trivial to care. a 4-point fft primitive is actually useful
<floatcomplex>
my best-effort forthlike interpreter on avr is about 20x slower than native c code to do the same thing, but it's such an artificial benchmark that it might not be fair to forth
<proteusguy>
veltas, re: OLPC - I was aware of it from attending an earlier PyCon in Dallas. Of course python was a big part of it. My participation was lobbying the Thai govt to adopt it and I was prepared to assist on the roll out. I only played with one for a while and didn't write any code for it although I intended to (with my staff) but it got canceled after the coup. So my involvement ended up being cut short before doing anything
<proteusguy>
interesting.
<siraben>
proteusguy: is OLPC still alive in other countries?
<proteusguy>
siraben, if it is I haven't heard about it for several years.
<MrMobius>
floatcomplex, I see what you mean. I was more curious as to why you wanted to know how fast forth is. do you have something in mind you want to do with it or just curious so you know in case you ever want to use it?
gravicappa has joined #forth
WilhelmVonWeiner has quit [K-Lined]
<floatcomplex>
MrMobius: mostly the latter, and mostly because if such a benchmark is written for flashforth, i can in turn see how good my forthlike interpreter is on avr by comparison
<floatcomplex>
although it's hard to say where to draw the line, w/r implementing the math primitives in C/asm and gluing them together in forth, vs implementing them from nothing in forth
<MrMobius>
floatcomplex, there are a few things you can do to speed things up like buffering the first item or two on the stack in registers
proteus-guy has joined #forth
dave0 has quit [Quit: dave's not here]
<siraben>
proteus-guy: do you know what kinds of issues they ran into? was it not feasible to create low powered laptops?
MrMobius has quit [Read error: Connection reset by peer]
iyzsong has quit [Ping timeout: 260 seconds]
iyzsong- has joined #forth
iyzsong- is now known as iyzsong
dave0 has joined #forth
<proteus-guy>
siraben, for Thailand it was just political. The machines were pretty good.
<proteus-guy>
I think the guy behind it Neopolit---something or other just moved on to other things. I think there may have been some political infighting or something. They did have a few good deployments around the world that I think would be considered successful.
<siraben>
Do you think mass mobile adoption replaces the need to have OLPC programmes?
<proteusguy>
siraben, no because the concept of OLPC was for kids to understand how it worked, be able to write their own code, and interact via a peer-to-peer swarm network. Mobile devices are locked down and you can't see the code. On OLPC there was a gear button that, when pushed, showed you all the python source code for whatever it was you were running. And you could change it and try new things.
<proteusguy>
dave0, oh yeah the J1 forth cpu is a great little thing!
<veltas>
Mass mobile adoption has been great, but let's not kid ourselves, kids who grow up with phones and tablets instead of desktop PCs are missing out
<floatcomplex>
lispmacs: i've argued before that even in compiled code, one SHOULD have to intentionally call a special function to write to eeprom, as compared to flash or regular memory, because you can only do so a limited number of times, and doing it in a hot loop would quickly kill the chip
<lispmacs>
floatcomplex: well, the eeprom memory is mapped to a different memory region than the ram and flash, and I think new words only compile to flash, so it is a bit hard to imagine myself accidentally writing to EEPROM.
<lispmacs>
seems like a non-issue to me, but you could come up with a new word that only writes to EEPROM space
<lispmacs>
like e@, that just takes a memory address and offsets it into the EEPROM memory space
<floatcomplex>
MrMobius: i meant not realizing you were writing to eeprom instead of any other regular variable because it's not obvious from looking at the code
<floatcomplex>
perhaps more of a problem in higher level languages
<floatcomplex>
and when working on other peoples' code
dys has quit [Ping timeout: 240 seconds]
<MrMobius>
floatcomplex, thats what I mean
<MrMobius>
if you have a pointer to ram and add or subtract the wrong offset, you could accidentally be pointing at eeprom right?
proteus-guy has joined #forth
proteus-guy has quit [Ping timeout: 246 seconds]
<lispmacs[work]>
the safety issues don't concern me personally, but I could see some advantages to separate words from a performance perspective, if once was being really careful with cycles. In AVR Flashforth, there is a 2 cycle overhead on @ and ! calls, due to the memory mapping
<MrMobius>
hmm, you can do a compare and jump in 2 cycles?
<MrMobius>
on windows 3.1 any program could access the whole memory so when one of them made a pointer mistake, it would write junk into another program's space
<MrMobius>
so anyway, things like that show how it's important to have some type of remedy
<lispmacs[work]>
I think trying to compare Window 3.1 desktop operating system management to memory type management in programming an AVR chip is quite the leap
<lispmacs[work]>
I don't see how having separate words really solves the problem. If you are using somebody elses code, they can just as easily have hidden the danagerous eeprom access call inside of one of their own words
<lispmacs[work]>
and a bad offset calculation into eeprom space might be a bummer, for sure, but any bad offset calculation is going to be bad thing in your system
<floatcomplex>
yeah when it comes to eeprom i'm less worried about accidentally writing to eeprom due to like bad offset calculation, and more about the next person who works on the code and doesn't realize it's not like other variables and they shouldn't make that loop faster
<lispmacs[work]>
a little `e' prefix to the variable name?
<lispmacs[work]>
would you be writing to eprom at all in a loop?
<floatcomplex>
(i'm specifically bent out of shape about this due to some evil c++ code that overrode the * operator, yes not the = operator but the * operator, in such a way that it could be used to make a simple assignment write to eeprom. no possible good can come from that use of overloading)
<floatcomplex>
lispmacs: not if you knew it was eeprom :)
<lispmacs[work]>
yeah, but I mean, if I'm going to create an eeprom variable, it is going to be something like "userpassword" which isn't going to be loop updated
<lispmacs[work]>
if I create something like "lasttempreading", I'm not going to put that to eeprom in the first place
<lispmacs[work]>
*point that
<lispmacs[work]>
again though, it would only be like a 2 minute project to implement those extra "safe words" if you wanted them
<MrMobius>
lispmacs[work], famous last words :)
<MrMobius>
probably fine though if its just your hobby project
<MrMobius>
assuming your not putting flashforth in an automoble ECU
<lispmacs[work]>
something constructive to mention would be the flashforth `inline' directive, so you could just alias ! to e!, if the goal was simply to make it obvious in code that an eeprom write was happening
Vedran has quit [Ping timeout: 256 seconds]
Vedran has joined #forth
gravicappa has quit [Ping timeout: 246 seconds]
<lispmacs[work]>
but at the end of the day, it is possible for somebody to use ! for eeprom writes. I was previously using Arduino-FVM, which I think didn't have any words for EEPROM writes
<floatcomplex>
under the hood it's actually doing something different than it would do to access sram or flash though
<floatcomplex>
right? otherwise avr-libc would just expose it in the address space too
<lispmacs[work]>
for sure, yes. IIRC, in AVR you access the eeprom through writes to a I/O register
gravicappa has joined #forth
<lispmacs[work]>
the I/O register(s) being accessible through normal ram memory accesses or through a special i/o instruction that is a little faster
WickedShell has joined #forth
Zarutian_HTC has joined #forth
dys has joined #forth
Vedran has quit [Ping timeout: 246 seconds]
Vedran has joined #forth
gravicappa has quit [Ping timeout: 240 seconds]
xek has quit [Remote host closed the connection]
xek has joined #forth
xek has quit [Ping timeout: 246 seconds]
Zarutian_HTC has quit [Remote host closed the connection]