WilhelmVonWeiner has quit [Read error: Connection reset by peer]
dave0 has quit [Quit: dave's not here]
sts-q has quit [Ping timeout: 265 seconds]
sts-q has joined #forth
Zarutian_HTC has quit [Read error: Connection reset by peer]
Zarutian_HTC has joined #forth
<KipIngram>
Ok, the LISP 1.5 book seems like a pretty good overview. I learned a few things and in particular see in a "kinda sorta" way what likely internal representations and algorithms are involved.
<KipIngram>
I couldn't go off and write a LISP program now - this was more of a "perusal reading" than a hard core study / solve all the problems sort of thing.
gravicappa has joined #forth
gravicappa has quit [Ping timeout: 265 seconds]
<KipIngram>
You know, one thing I like about my dictionary structure is that all words are "redefinable in place."
<KipIngram>
I.e., even after I've compiled a bunch of definitions using some word, I can re-define it and have the new definition take effect everywhere.
<KipIngram>
If I want to - that's not necessarily automatic.
<KipIngram>
The structure just allows for it.
<KipIngram>
It's because I have a pointer for each words PFA; there's no "implicit PFA location" like there is in FIG.
<KipIngram>
So I don't have to have a special class of "vectorable" words.
f-a has joined #forth
Monev has quit [Ping timeout: 260 seconds]
Monev has joined #forth
jedb__ is now known as jedb
dave0 has joined #forth
<dave0>
maw
Zarutian_HTC has quit [Ping timeout: 265 seconds]
rixard has quit [Read error: Connection reset by peer]
rixard has joined #forth
Zarutian_HTC has joined #forth
nmz has joined #forth
gravicappa has joined #forth
Monev has quit [Ping timeout: 240 seconds]
andrei-n has joined #forth
f-a has quit [Quit: leaving]
wineroots has quit [Remote host closed the connection]
<proteusguy>
KipIngram, re: " just the specific notion that a great architecture can emerge from a vacuum." absolutely agree. And too many snake oil salespeople and, worse yet, programmers still claim this.
<KipIngram>
I've designed a lot of things over the years, but the thing I was always best at was digital logic design. Before I ever started with a schematic, I would sit and think. I could hold a fair amount of logic in my mind well enough to evaluate and reject possible approaches without having to "really" go down that road. Similar to mentally executing a piece of code, except with hardware and parallel signals.
<KipIngram>
Obviously I could "simulate it" in my mind in any sort of complete or cycle accurate way, but could tell (often) when something wasn't going to work, and I'd lay that idea aside and try something new.
<KipIngram>
Usually by the time I started doing a schematic I KNEW what I was about to do was going to work. I knew I had some bits and pieces to work out the details on, but I knew I wasn't going to run into an insurmountable problem.
<KipIngram>
Sometimes this would take days, if the piece of work was significant.
<KipIngram>
I thought of that sitting and thinning as the best possible application of my time.
<KipIngram>
When I did start doing the schematic, I went straight throough it. No iterating.
<KipIngram>
In his second book (after The Seven Habits of Highly Effective People), or at least a "later book" called "First Things First" Steven Covey laid down the principle "all things are created twice." First they are imagined, and then they are realized.
<xybre>
Plus prototypes and failed production units ;)
<KipIngram>
I believe in "imagining" WELL and THOROUGHLY.
<KipIngram>
Yes, it's possible to *imagine* the failed prototypes.
<KipIngram>
And failed prototypes in electronics take weeks.
<KipIngram>
Board layout, PCB fab, assembly, etc.
<KipIngram>
It's not a file you can edit.
<KipIngram>
Well, it is.
<KipIngram>
But not JUST that.
<xybre>
Good hardware simulators are hard to come by
<KipIngram>
And they were impossible to come by in the 1980's when I was active in this area.
<KipIngram>
I saw some early work by Mentor Graphics at a trade show once and was fascinated by it.
<KipIngram>
But it was early days.
<KipIngram>
That stuff got better in the 1990's, while I was still active, but I was with small companies and we couldn't afford $40k / $50k pieces of software.
<KipIngram>
With special workstations to run it on.
<xybre>
There's some simple ones that run in browsers now, but the big ones I think are still like that
<KipIngram>
Yeah. What beat the hell out of me in the earl FPGA days (and still) was that the chip vendors want to make a profit center out of their software. I used to flatly tell the people that came calling that there was NO CHANCE of us using their chips unless we got the software for free. I just refused to hand over money for that. And I managed to make that work for a while - later on they got more "corporate"
<KipIngram>
about it, but in the beginning I was able to talk anumber of them out of free copies.
<KipIngram>
I guess we represented enough possible volume. Early days.
<KipIngram>
These days that volume would be a spit in the ocean.
<proteusguy>
KipIngram, yeah the hardware folk never quite understood the real value of software was in getting devs to use it so they'd buy your dang chip!
<KipIngram>
I was accustomed to PAL programmable logic, which was totally transparent. You could look in the data book and infer the format of the fuse file.
<KipIngram>
Then FPGAs come along, and they wouldn't tell me what the bits of the fuse file meant, and it drove me crazy.
<KipIngram>
This frigging undocumented bit stream.
<proteusguy>
KipIngram, fortunately that's slowly becoming more open.
<KipIngram>
Yes, at last.
gravicappa has quit [Ping timeout: 240 seconds]
<KipIngram>
Decades later. :-)
<KipIngram>
I used to have dreams of being able to reconfigure bits of logic on the fly.
<KipIngram>
We made equipment that programmed programmable devices - I used to think about having "accelerators" that we could install in the FPGA on a per-device algorithm basis.
<KipIngram>
(Algorithm - our word for the bit of code specific to a device that made the programmer able to handle it).
<KipIngram>
We had a custom language called DPL we wrote algorithms in, and a third of my team did nothing but write such algorithms.
<KipIngram>
The owner had created DPL way back in the day, using the usual compiler tools like yacc and so on.
<KipIngram>
I regard it as the primary reason his company became #1 in the programming business.
<KipIngram>
Our number of devices supported just flew by the competition.
<KipIngram>
And when we did a new programmer, we'd just change the code generator of the DPL compiler to accomodate it, and instantly ALL of those devices were supported on the new product. The competition just couldn't do that.
gravicappa has joined #forth
<proteusguy>
I believe it. Being able to make your own DSL shows mastery of the domain and gives you the ability to multiple that value. That's why I like forth.
<KipIngram>
The guy was brilliant. He could be a complete asshole at times - he'd never worked for anyone else in his life, and he just didn't undnerstand what the boss's opinion could mean to people.
<KipIngram>
He started the company right out of college at Rice.
<KipIngram>
He was also an analog circuitry wizard.
<KipIngram>
A generation younger than you usually found analog wizards.
<KipIngram>
There were days I didn't like him, AT ALL. But I had huge respect for his abilities.
<KipIngram>
And he gave me a sandbox to play in, and he paid my salary. I appreciated those things.
<KipIngram>
I was able to send my wife to graduate school on that financial success.
<KipIngram>
And then later after those glory days had passed for me she brought home the big bucks. :-)
<KipIngram>
She wound up one of about half a dozen people in the world fully expert in a technology the offshore oil folks call "flexible pipe." It's this sophisticated multi-layer pipe technogolgy, with layers for sealing, layers for pressure handling, etc. etc.
<KipIngram>
Some of the strength layers are made of these groovy little pieces of interlocking metal, that can move and flex but still resist loads.
<proteusguy>
Good call on the wife there! ;-)
<KipIngram>
Oh yeah man, I don't know that I really deserve her. I wasn't going to get married again, after my nightmare of a first marriage.
cmtptr has quit [Ping timeout: 240 seconds]
<KipIngram>
For about a year I chased every woman in sight and had a blast.
<KipIngram>
Then I met her and decided almost instantly that she was a keeper after all - turned on a dime.
cmtptr has joined #forth
<KipIngram>
Pro tip: Early 30's is a great time for a guy to be single. It's a buyer's market.
<KipIngram>
The women a few years younger are starting to get serious about things and losing interest in the flashy bad boys, and the women a few years older are starting to get... desperate.
<KipIngram>
A guy who's at least not ugly, has an education, and is holding a good job turns out to be a hot commodity around that time.
<veltas>
Can confirm, although I'm late twenties and happily engaged, I can tell that's the way the market is
<veltas>
I certainly wouldn't advise making long term decisions to try and remain single at that time
<veltas>
But if you're having trouble in your 20's then maybe it's good to know if you can stay in good shape and not be a total loser you will find it easier later
<KipIngram>
Agreed.
<KipIngram>
It wasn't by choice I wound up single at that age. Well, actually it was my choice, but not one I savored.
<KipIngram>
And that's exactly what my advice would be - at least try not to get depressed if you're young and not a big hit with the ladies - the game changes quite a lot over time.
<KipIngram>
Anyway, now it's a quarter century later and things have been great. For me, second time was the charm.
<veltas>
Nice
<KipIngram>
I got my two oldest daughters out of the first marriage, so if I had it to do again I'd go through it again, just to get them. So it wasn't a total loss. :-)
<veltas>
Yep
<KipIngram>
You know, this LISP primer has a really nice fully fleshed out example at the end - some symbolic math. That's gold; sometimes just carefully going through something like that teaches more than anything else.
<KipIngram>
It really, REALLY looks like code from the 1960's.
<KipIngram>
I remember seeing similar weirdly abbreviated names in old FORTRAN programs.
<KipIngram>
So, speculating on the internal operation of a LISP system, am I getting the right idea? The LISP entity most similar to the Forth "dictionary" looks like it would dynamically grow and contract during execution. Would that be what the primer called the "a-list"?
<KipIngram>
It looks like in LISP that structure is a much more "active participant" in things than the Forth dictionary is - I think of the Forth dictonary as relatively static during application executionn.
<KipIngram>
But I guess that makes sense, since LISP has this ever-changing name scope.
<nihilazo>
so what I've read about writing assemblers in forth (ones that run "inside" forth, defining words for different opcode etc) would suggest that they are single pass, but I'm confused if it's possible to, for example, define a label and reference it before the location it's defined. To make that work in a single pass assembler would you need to declare labels before their locations are given?
<KipIngram>
To do that in a single pass you do something similar to how Forth's IF ... THEN works. IF and THEN are both immediate words that run at compile time. IF compiles a conditional jump, but it doesn't know where it needs to jump to yet, so it allocates the space for the jump target, put the address of that space on the stack, and puts a "code" on the stack. Then, later, THEN checks for that code; if it's there,
<KipIngram>
great - if not, error. THEN compiles no code itself - but it knows the jump target, and it goes and patches that address into the spot that IF allocated.
<KipIngram>
You can do that same kind of trick in assembly.
<KipIngram>
Reverse jumps work similarly - the first word puts the target address and a code on the stack; the later word confirms the code and compiles a conditional jump to that target.
<KipIngram>
In neither case do you need to define a "label" in the dictionary or some other symbol data structure.
<nihilazo>
hmm ok
<KipIngram>
The trick is to use the stack to communicate information forward from earlier immediate words to later immediate words.
<nihilazo>
I'm still not entirely sure how that works but I kinda get it?
<KipIngram>
I wrote some partial x64 assembler words for my Forth, and in the arena of jumps (conditional and unconditionnal) it didn't really "look like" traditional assembly.
<KipIngram>
Get a pencil and paper and step through a couple of examples; it'll click.
<KipIngram>
In all cases once you get past the whole thing all the information you need to define the code exists. You just sometimes have to wait a while after you first need it to get it.
<KipIngram>
Leaving a blank spot and backpatching it later is perfectly fine.
<nihilazo>
I understand how that works for jumps
<nihilazo>
but I'm slightly confused how I'd use it for other things
<KipIngram>
Like what?
<nihilazo>
for example in uxn (my target platform), there are memory addresses that you're meant to write memory addresses to as vectors
<nihilazo>
like an interrupt type thing
<KipIngram>
Ok.
<nihilazo>
and you need to do those at the start of the program
<KipIngram>
Well, these are documented addresses, right?
<KipIngram>
?"
<KipIngram>
Ooops - sorry.
<KipIngram>
My dog started to fall off the sofa, and hit the keyboard.
<KipIngram>
"Problems cats never have" (tm)
<nihilazo>
yeah you know the addresses to write the vectors to but the vectors themself are in your own code
<nihilazo>
so let's say you have a screen drawing routine at 0x0280, you would write 0x0280 to the address for the screen vector
<nihilazo>
I am explaining this badyl, sorry
<KipIngram>
Yes, so ok. So I'd let those be determined at compile time, and then I'd set them at startup. I have some things like that in my Forth - I don't know where it's going to be loaded in memory, and there are a things that are global addresses I have to set. So code that isn't actually part of my system but runs first, at startup, patches that stuff up.
<KipIngram>
If you must have these things set before you get to do ANYTHING, then you have a bit of an issue onn your hands.
<KipIngram>
One alternative might be to put a table of jumps at the start of your code.
<KipIngram>
Point those vectors into your jump table, and let the jumps there take you the rest of the way to your target.
<KipIngram>
You'd allocate them first as blank spots, and then fill them in during compilation as you learned where your code was going to be.
<KipIngram>
Does your code image get loaded in a specific place every time?
<nihilazo>
yeah
<nihilazo>
I think so
<nihilazo>
yeah it does
<KipIngram>
Ok. Then if your code image gets loaded at X, and a jump instruction takes N, then the jumps would be at X, X+N, X+2N, etc. - you'd point the vectors at those spots.
<KipIngram>
So your image would start off with
<KipIngram>
JMP X1
<KipIngram>
JMP X2
<KipIngram>
etc.
<KipIngram>
Fill in Xi when you know what they are.
<KipIngram>
Maybe that doesn't feel like a pure 1-pass operation to you, and I guess it's not. When you backpatch that's a bit like a little piece of a second pass, isn't it?
<KipIngram>
But it's easier to do than a full-on multi-pass setup.
<KipIngram>
Easier because you don't have to build a general symbol table mechanism.
<nihilazo>
ok
<nihilazo>
maybe it would be easier to just build a multipass assembler. But I like the idea of doing this within forth
<nihilazo>
and doing multiple actual passes isn't really possible if you're writing assembler as forth words
<KipIngram>
Well, you COULD write a multipass assembler in Forth, but you'd have to build the traditional symbol table and so on - you wouldn't be able to take full advantage of what Forth already gives you.
<nihilazo>
yeah
<nihilazo>
I just don't really want to have a jump table in my output code, for some reason
<nihilazo>
even though it's very few bytes in reality
<KipIngram>
Well, you're writing to please yourself, so... you're in charge.
f-a has joined #forth
<KipIngram>
You might consider cuckoo hashing for your symbol table if you do that. It's got fast lookup time.
<nihilazo>
cuckoo hashing?
<KipIngram>
And makes good use of table space.
<KipIngram>
Yeah, it's a particular hasing method. There's a Wikipedia article.
<nihilazo>
ah ok
<KipIngram>
Felt like something that would implement cleanly in Forth.
<KipIngram>
It offers guaranteed read speed, but inserts might start taking longer as the table becomes fuller. The article said it was pretty straightforward to get 95% space utilization in your table before inserts became prohibitivey expensive.
<KipIngram>
prohibitively
<nihilazo>
ah ok
<nihilazo>
cool
Zarutian_HTC has quit [Remote host closed the connection]
dave0 has quit [Quit: dave's not here]
<siraben>
remexre: have you ever used bisimulation?
<siraben>
in the context of proving semantic preservation of compiled code wrt. source language, I know it also can be used to establish equivalences between state transition systems and process calculi
<siraben>
all formally verified in Coq, I might try the same but target other stack machines/VMs.
<KipIngram>
"proving semantic preservation of compiled code wrt. source language" - that would be "making sure the code does what it's supposed to"?
<siraben>
KipIngram: yes but I was stating it precisely
<KipIngram>
:-)
<KipIngram>
Just poking at you a little.
<siraben>
you define a relation between the source language and target VM state, then show that when the source language takes a step, the VM takes one (or more) as well
<siraben>
hehe
<siraben>
so in other words, programs don't get stuck
<KipIngram>
One of the supposed assets of Forth (done right) is that you have short definitions that you can simply look at and "know" are right.
<KipIngram>
Using whatever mechanism Goedel found humans to have that machine intelligence doesn't.
<KipIngram>
I almost certainly spelled that wrong. :-(
<siraben>
Well this is quite unrelated to Gödel, but I see what you mean.
<siraben>
That's also an alternate spelling
<KipIngram>
Oh, shoot - I didn't. That was the alternate that I see out there.
<siraben>
Forth programs are quite compositional, so I'm certain that the properties of short words could be almost automatically proved
<KipIngram>
Right - I didn't think it was really the same thing.
<KipIngram>
I imagine so.
<siraben>
Proofs, like functional programs, compose very well. It's annoying to build up the theory at first (mostly doesn't happen in real projects), but once you do, for instance, someone might write a dead code elimination pass (along with a proof of correctness) and someone else a pass to optimize arithmetic (with proof)
<siraben>
then combining the two passes and you get a bigger, correct pass for free
<KipIngram>
I actually like the idea of provable correctness. If we had more of it we might not have such crap operating systems on the market.
<siraben>
They even have a verifiable C volume, but I don't know enough yet to tackle that
<f-a>
indeed that is a superb resource
<siraben>
f-a: fellow FPer? ;)
<KipIngram>
I'm a big fan of "compile time smarts, run time performance."
<f-a>
yeah, tho I mostly do crap programs
<siraben>
Forth is funny in that you basically are already writing programs in the target VM (or using other words built up from primitives)
<KipIngram>
Forth could be understood by small children, in my opinion.
<KipIngram>
It has a childlike simplicity.
<KipIngram>
Say this, this happens.
<siraben>
Of course all this formal stuff is not a silver bullet, probably out of reach for most programmers since you'd need a good understanding of mathematics and proofs to apply them to programs
<siraben>
so YMMV
andrei-n has quit [Ping timeout: 252 seconds]
<f-a>
UNSAFE-PERFORM-IO
<siraben>
f-a: gasp the unutterable sin
<siraben>
"every time you use unsafePerformIO, a kitten dies"
<KipIngram>
Hahaha - I had to look that up.
<KipIngram>
"I promise..."
<KipIngram>
Basically telling the compiler to trust you.
f-a has quit [Ping timeout: 252 seconds]
f-a has joined #forth
pareidolia has quit [Ping timeout: 260 seconds]
wineroots has joined #forth
andrei-n has joined #forth
<KipIngram>
By the way, the hashing method alluded to by the LISP primer sounded very similar to that cuckoo hashing I posted a link to a couple of weeks ago and recommended to nihilazo earlier this morning.
<KipIngram>
I really like the combination of simplicity and effectiveness that offers.
<KipIngram>
I was reflecting on functional programming this morning, and I decided that one of the reasons it's never appealed to me is because of my embedded background. The first thing I think about when I think about writing software is that the software is going to DO SOMETHING. It's going to cause an effect. Perhaps only on the memory, but more often on some other aspects of the hardware. Its purpose is to
<KipIngram>
*control* something. So the very thing I'm interested in is the side effects. I feel like when you're mostly interested in side effects functional programming loses some of its "naturalness."
<KipIngram>
I probably should do some self study on theorem proving or something like that - I might wind up with a better appreciation.
mark4 has joined #forth
<mark4>
REALLY annoying that C cannot tell you the ADDRESS of a function at runtime given its name :P
<kiedtl>
C isn't Python
<mark4>
c isnt forth
<KipIngram>
Unless you've got debugging information around all that symbol info is gone, right?
<mark4>
strip -R .comment
<KipIngram>
Well, I guess what I meant by that is that the, uh, "academic" purpose of a compiler is to eliminate all that stuff.
<KipIngram>
But I guess that only truly applies after you link.
f-a has quit [Read error: Connection reset by peer]
<KipIngram>
So what were you tryinng to do that a function pointer doesn't give you?
gravicappa has quit [Ping timeout: 265 seconds]
gravicappa has joined #forth
f-a has joined #forth
<tabemann>
hey guys
<tabemann>
KipIngram, I thinkk given a string containing a function name get the function pointer
<tabemann>
which obviously C can't do
f-a has left #forth [#forth]
<dys>
well, on any modern POSIX system C can do that: dlopen, dlsym
<tabemann>
but that's a feature of POSIX, not of C
andrei-n has quit [Quit: Leaving]
<KipIngram>
Yeah - it's not something I'd expect a traditional, straightforward compiled language to do.
<mark4>
dys a c application can use dlsym to get the address of a function
<mark4>
a c library can not use dlsym to get the address of a function in an application
<mark4>
crippled
<remexre>
siraben: nope, but I'm familiar with it's existence/usefulness; I'll give that presentation a look, thanks!
<remexre>
mark4: hm, does dlsym(RTLD_DEFAULT, "whatever") work?
<remexre>
looks like no :(
<mark4>
remexre, i would need to add that to my library which when linked against ANYONES application, the library would need to do that
<mark4>
on a stripped application
<mark4>
wont work
<remexre>
oh, well, if it's stripped you're SOL no matter what
<remexre>
I wonder if you could do something sick and twisted to gnu as to have it build a forth-like dictionary in the .text section...
<mark4>
remexre i would need an associative array of strings for menu item names and & function addresses
<mark4>
and i would need the end user to create that associative array at edit time
<mark4>
possibly with macros
<remexre>
yeah, I was thinking of defining a macro for .type, which then maintains a linked list using as' macro system
<mark4>
which again. is a FUCKING nightmare becauuse theres no reason wny i cant have a BLAH menu item inside both the FOO and BAR pulldowns
<mark4>
not a linked list. an array
<remexre>
right I mean you'd turn it into an array at runtime
<mark4>
menu_association_t array which they populate with string menu item names and function pointers
<mark4>
they could then create a json file which references that array
<mark4>
only. ill need one array per pulldown and another one for the menu bar
<mark4>
meaning im practically building the ENTIRE FUCKING MENU at compile time
<mark4>
instead of dynamically creating it at run time
<mark4>
which is what im trying to achieve
<mark4>
i need a way to offload ALL that compile time bullshit to run time
<mark4>
creating compile time intermediate structures just so i can dynamically create the run time structures mkeas those run time structuers entirely NOT dynamic
<remexre>
the compile-time structure would just be for looking up name->function pointer
<remexre>
but doing it by messing with as is definitely the wrong thing
<mark4>
no, they would have to give the name of the menu item within the pulldown and its associated function pointer
<mark4>
tne only other item in the pulldown menu item is the shortcut key escape seauence
<mark4>
and every single pulldown menu would need its own menu item associative array
<mark4>
and the menu bar would also need an associative array of pointers to associative arrays
<mark4>
menu bar name for the pulldown and a pointer to the array of associations for that one pulldown
<mark4>
yup. statically creating structures so i can dynamically recreate them elsewhere
<mark4>
to make them look like im dynamically creeating them
<mark4>
utter bullshit
<dys>
IIRC it's not about the strippedness, it is about linkage. Static functions cannot be dlsym'd, they need external visibility
<mark4>
yes but the EXECUTABLE is already linked and stripped
<mark4>
not yet executed
<mark4>
the ENTIRE freeking UI can be dynamically generated at runtime based off of a json file
<mark4>
define a screen. put windows in that screen. put menu bar in that screen. put pulldown menus in that bar. put menu items in that pulldown
<mark4>
define attributes for windows, pulldowns etc etc etrc
<mark4>
ALL at run time based off of a json file
<mark4>
except. CANNOT associate function addresses with names dynamically
<mark4>
only statically
<mark4>
someone said i should be using QML lol
<mark4>
/facepalm
Gromboli has joined #forth
<dys>
well, just don't link it statically, then you can. if you don't put function in the dictionary for performance reasons you cannot do the lookup there either...
<mark4>
no
<mark4>
because anything i link dynamically to at run time STILL increases my runtime footprint
<mark4>
which is currently less than 53k which is the size of my stripped elf file
<mark4>
here is my list of dependencies... dep_array[]={};
<mark4>
and its staying that way
<mark4>
other than stdio, stdlib, etc etc
<mark4>
if a library is not guaranteed 100% to be on your system its not going to be a dep here
<mark4>
in fact. if its not 99.99999% guarnted to already be loaded on your system it wont be a dep here
<mark4>
no matter how i swing this NO part of my menus for this UI can be dynamically generated at run time
<mark4>
they absolutely have to be statically generated at compile time :/
<mark4>
and thats not acceptable
<dys>
I don't get it... just implement a dlsym() yourself then to siute your needs? C gives you all that's needed...
<mark4>
sure
<mark4>
and you create a ultra geeky executable that links agianst my lib and is stripped
<mark4>
boom. fail
<remexre>
also wait I've run linux systems before without a libc.so...
<mark4>
remexre, you were never without a libc of some sort
<mark4>
there must have been a ulibc or something like it somewhere
<remexre>
nope, kernel booted to my forth
<mark4>
which cant run my application
<mark4>
and is not a real world scenario
<mark4>
as much as i would love it to be :)
<dys>
A branch of stubforth does that as well. Only dependency is linux syscalls
<mark4>
ALL of my forths are stand alone. i treat the linux kernel as my bios
<mark4>
i dont link against ANYTHING external with them
<mark4>
but.... thats not how the real world works.
<mark4>
this is not forth im developing here right now :/
<remexre>
how do you feel about linking to BFD
<remexre>
should be on 99.9% of systems that ship ld
<mark4>
linking is not the solution
<remexre>
right, bfd is how ld looks at objects
<remexre>
that plus a macro to dump functions into a particular section might work?
<mark4>
and it is entirely dependent on an unstripped executable
<mark4>
or objects
<remexre>
no, that's why you're creating a new section
<mark4>
CANT do that at run time
<remexre>
you don't need to define functions at runtime (or if you do, you're much "deeper in" than I realize)
<mark4>
[executable with all functions here]<--[user interface DESCRIPTION here]
<mark4>
stripped executable
<dys>
well, you need to do *something* at runtime. you can either use the standardized dynamic linker for it or homebrew something
<dys>
and again, strippedness doesn't really matter
<mark4>
the ONLY thing i can do at run time is reference a compile time statically generated array
<dys>
the dynamic linker doesn't use debug info at all
<mark4>
which contains 99.99999999999999999999% of the ENTIRE menu structure items
<KipIngram>
Holy cow - turn my back for a few minutes and this place just blows up... :-)
<tabemann>
the problem with the idea that "C is not a low level language", then what is, assembly?
<tabemann>
from glancing at that article, it implies that assembly is not a "low level language"
<tabemann>
then what is? custom microcode?
<boru>
To be a purist, pedantic shite, if it most be translated, then it's not a "low level" language.
<tabemann>
to me the difference between a low level language and a high level language is if one has direct access to the addressing space
<tabemann>
which, by that standard, C definitely is a low level language, and so is Forth and even C++
<boru>
To what degree? Virtual memory? What memory model?
<tabemann>
that's a matter of whether code is running under a virtual memory OS in user space or not, not what language it is written in
<tabemann>
e.g. C can run both on bare metal, in supervisor mode but under a hypervisor, and in user mode under a virtual memory OS
<boru>
I was being a bit facetious; I think that as soon as an "abstract machine" is involved, you're not talking about "low level" anymore.
<boru>
ISO C has the concept of freestanding and hosted implementations. That's it./
<tabemann>
the thing is then even assembly is not "low level"
<tabemann>
because assembly code doesn't see micro-op translation and register renaming and like
<boru>
Precisely.
<tabemann>
but rather has an "abstract machine" presented to it by the hardware
<boru>
The thinly veiled point I was trying to make that "levels" are nonsense.
<tabemann>
but then that does not address the point that distinguishing "low level" from "high level" based on ability to address RAM, whether in bare metal or in virtual memory, is a useful one
<tabemann>
if we just say "oh well, then all languages are high level" we don't get anywhere
<boru>
That is the point of programming languages, however.
<tabemann>
whereas there's a fundamental difference between, on one hand, C and Forth on one hand and Python and Haskell on the other
jevinskie[m] has joined #forth
<boru>
What features they have is what makes them suitable for one problem or another.
<boru>
To reiterate, I am being pedantic.
<tabemann>
the problem with being pedantic is that it often isn't useful
<tabemann>
like in this case, by essentially saying "all languages are high level", you ignore the fact that important distinctions can be made between classes of languages
<boru>
Sure e.g. compiled and interpretted.
<boru>
As for what features are exposed by a given languge, "low level" and "high level" are nonsense.
<tabemann>
no, they're not nonsense - they essentially mean whether languages allow access to the addressing space or not
* TangentDelta
throws down a PDP-11/03 with a KUV11 Writeable Control Store
<TangentDelta>
There. A true system for writing low-level programs on!
<boru>
I think they're nonsense.
<tabemann>
and as for compiled and interpreted, that is not a firm distinction, due to things like languages with both interpreted and compiled modes (Forth and various Lisps), JIT's, and like
<tabemann>
well you're a pedant, that's why
<tabemann>
to you, the only low level language is microcode
<TangentDelta>
Oh wait...the MCP-1600's used in the LSI-11 are microcoded themselves.
<boru>
Well, I baited with you with that distinction on purpose.
<boru>
Would you consider being able to write to a device, say, a file descriptor, such as a socket, or a file, as being "low level"?
<tabemann>
well what is your point, aside from lumping C with Java with Haskell with Python all in one category
<tabemann>
boru: that's a question of what API's are exposed, but the programming language
<boru>
I think you're missing my point, actuallyt.
<tabemann>
your point is that all languages are high level, even assembly, which is an utterly useless point
<tabemann>
take this:
<tabemann>
<boru> Would you consider being able to write to a device, say, a file descriptor, such as a socket, or a file, as being "low level"?
<tabemann>
you can say the same exact thing about assembly
<tabemann>
because you write assembly code that runs under a host OS, which gives it access to things such as FD's, sockets, and files through system calls hidden behind a standard library just as well
<TangentDelta>
So...if you write C or assembly and compile it for x86 and run it on a modern processor, the processor executes it in a non-sequential, superscalar way.
<TangentDelta>
C and assembly assume the code is executed sequentially
<tabemann>
yes
<tabemann>
hence assembly is a "high level language"
<kiedtl>
At this point the phrase "high level" has lost its meaning.
<TangentDelta>
So that article is saying that C isn't low-level because the x86 processor is re-interpreting the bytecode into it's eldritch superscalar mechanism.
<tabemann>
yes
<TangentDelta>
*into its
<tabemann>
and by that logic so is assembly
<tabemann>
because the x86 processor is re-interpreting the hand-written instructions into its eldritch superscalar mechanism
<TangentDelta>
I think that trying to program in assembly at that superscalar x86 spaghetti level would drive you insane.
<tabemann>
kiedtl: no, it just makes sense to redefine "high level" to something that actually makes sense and is useful
<TangentDelta>
In a modern CPU, a lot of it is machine-learning accelerated lol
<boru>
So, to reiterate, inventing criteria for "levels" is nonsense, since ultimately, everything is translated.
<tabemann>
e.g. whether a language has the ability to directly address memory
<tabemann>
boru: you're arguing that because something is translated one can't make any distinctions between things
<boru>
Hence, the actual point of programming languages.
<tabemann>
and I'm arguing that you can make distinctions that actually matter and which can be reasonably defined
<tabemann>
if one distinction doesn't work, make a different one
<boru>
Right. Let's discern programming languages which can make ham sandwiches.
<boru>
The features of a given language matter. They are, afterall, just tools with different features.
<boru>
Ergo, with specific suitabilities.
<tabemann>
boru: simple question for distinguishing the language: without dealing with things like FFI's, can the language make a machine segfault?
<boru>
You might as well ask me to solve the halting problem.
<mark4>
boru that applies to everything except forth bcause forth allows you to extend forth to ass the language features you need
<tabemann>
boru: that's not like the halting problem
<boru>
It is, really. Will a perl interpretter segfault?
<kiedtl>
^^ Any program can segfault.
<tabemann>
boru: if it does not allow access to the addressing space, no
<boru>
Precisely.
<mark4>
Alan Turing proved in 1936 that a general algorithm to solve the halting problem for all possible program-input pairs cannot exist.
<mark4>
i would disagree with that
<tabemann>
you're missing the fucking point guys
<boru>
I think you're missing the point, actually.
<mark4>
the algoritm is to walk through the code with all possible input (invinite data)
<tabemann>
Python e.g. does not expose the addressing point to the user
<tabemann>
without writing code that uses the FFI
<mark4>
that IS a working but not viable algorithm
<tabemann>
*space
<tabemann>
I specifically said "segfault" for a reason
<tabemann>
not "crash" or "raise an exception" or like
<TangentDelta>
I ususally make the distinction between an interpreted and a compiled language. Python is compiled to bytecode that is interpreted by a software mechanism.
<boru>
What does the FFI have to do with it? You can write C code which _should_ cause a segfault, but might also limp onward with corrupted memory.
<boru>
An interpretter may also do the same.
<TangentDelta>
C is compiled to bytecode that is interpreted by a hardware mechanism.
<tabemann>
boru: because FFI's often expose memory that is otherwise hidden from the user
<boru>
TangentDelta; I take it you haven't written much C.
<kiedtl>
>bytecode
<TangentDelta>
boru: Not targeting x86, no.
<kiedtl>
What do you mean? machine code?
<tabemann>
bytecode, machine code, what's the difference
<mark4>
tabemann, exactly
<boru>
I didn't make any distinction about ISA, nor does C.
<kiedtl>
tabemann: bytecode is confusing in this context because it can be confused with, say, java bytecode
<kiedtl>
or .net clr bytecode, or whatever
<mark4>
oh. there is one change i need to make to that code so it will pass scan-build make
<mark4>
but we will gloss over that for now :P
<tabemann>
kiedtl: anyone who automatically associates the term "bytecode" with VM's is an idiot
<TangentDelta>
I've written and compiled C for an embedded MIPS CPU for example and looked at the actual machinecode bytes (bytecode) in the resulting binary
<kiedtl>
tabemann: thank you for your constructive insult.
<mark4>
TangentDelta, i feel your pain lol.
<boru>
scan-build is a bit shitty, ime. I'd recommend invoking it per TU.
<TangentDelta>
Bytecode is...byte code...
<tabemann>
kiedtl: well, the matter is that there's nothing stopping me from writing an implementation in Verilog and uploading it to an FPGA...
X-Scale` has joined #forth
<mark4>
no actually i do it on the entire prject and have ZERO bugs except for two i introdced with this code due to a change i KNOW i need to make
<mark4>
so zero bugs
<mark4>
ezpz
<TangentDelta>
It's code executed by some mechanism that is encoded in a binary format.
<boru>
no no, I mean the scan-build script itself.
<tabemann>
anyone who doesn't realize this is an idot
<mark4>
oh
<TangentDelta>
The mechanism can be a Java VM, an x86 processor, a 6502...
<boru>
clang-analyzer is great.
<tabemann>
yes
<mark4>
i cant enforce clang use for building this :(
<mark4>
or i would
<kiedtl>
Yes, but 'machine code' is less ambiguios
<mark4>
for a start libtool REFUSES to honor my CC setting and invokes gcc
<tabemann>
a single ISA can be implemented in hardware or software
<tabemann>
whether one calls it "bytecode" or "machine code" is completely irrelevant
<mark4>
compiled forth is virtual cpu assembler
<tabemann>
and w.r.t. hardware it can be in an ASIC or in an FPGA
<mark4>
or is physical cpu assembler
X-Scale has quit [Ping timeout: 252 seconds]
X-Scale` is now known as X-Scale
<TangentDelta>
tabemann: Or a collection of crabs in tubes