<xentrac>
solrize: signed int overflow in C is UB, but signed int overflow isn't UB in any hardware architecture I know of
<xentrac>
jrtc27: I think there was a long time where if you were doing 3D stuff you couldn't ignore mips
<xentrac>
well, not that long. like 10 years
<solrize>
xentrac, the UB is serious because compilers are allowed to assume that signed arithmetic doesn't overflow. for example, n+1 > n for every n is a legitimate optimization invariant for signed ints in C, even though it's false in 2s complement
<solrize>
i don't see a text dir
<solrize>
i mean that's a bare git repo
<pabs3>
git clone should work though
<solrize>
oh i was able to view the file by dropping the .git suffix
<solrize>
looking at it, the historical stuff about lisp is interesting but the thing i was after this morning was code density, e.g. thinking of doing something like sweet16 on the avr
<solrize>
i think it is not worth it though
<solrize>
i'm not sure it's worth trying to use lisp on a tiny machine
<solrize>
e.g. ulisp on the atmega328
<solrize>
raspberry pi pico is another matter
sm2n has quit [Read error: Connection reset by peer]
riff-IRC has quit [Remote host closed the connection]
riff-IRC has joined #riscv
BOKALDO has joined #riscv
compscipunk has quit [Quit: WeeChat 3.2]
sm2n has joined #riscv
<sorear>
(facetiously, one might argue that ignoring multi-precision positions riscv on the leading edge of the post-quantum transition; the currently studied algorithms for that don't use integers wider than about 16 bits, except for the SIDH family which is so slow it won't be usable without dedicated hardware anyway; also a lot of ECC code uses narrow-radix representations, which make muls faster at the expense of making ADC useless)
<solrize>
huh? i don't understand any of that except ECC tends to use prime fields these days
<sorear>
the original curve25519 code divided (255 bit) coordinates into 10 words with 25 or 26 bits in each word. multiplying two coordinates could be done with 10*10 multiply-add operations, only handling carries at the very end
<sorear>
(also, it was entirely done with floats, because the Pentium had much higher float multiply performance than integer multiply)
<solrize>
yeah that was to use float64's with 64 bit mantissas
<solrize>
53 bit i mean
<sorear>
there have also been integer implementations using similar techniques
jimbzy has joined #riscv
jimbzy has quit [Changing host]
jimbzy has joined #riscv
pabs3 has quit [Ping timeout: 245 seconds]
pabs3 has joined #riscv
Maylay has quit [Ping timeout: 240 seconds]
Maylay has joined #riscv
winterflaw has joined #riscv
valentin has joined #riscv
hendursa1 has joined #riscv
hendursaga has quit [Ping timeout: 244 seconds]
charlesap[m] has quit [Quit: You have been idle for 30+ days]
nmeum has quit [Remote host closed the connection]
nmeum has joined #riscv
khem has quit [Ping timeout: 272 seconds]
EmanuelLoos[m] has quit [Ping timeout: 276 seconds]
pierce has quit [Ping timeout: 276 seconds]
BOKALDO has quit [Quit: Leaving]
avoidr_ is now known as avoidr
ntwk has quit [Quit: ntwk]
CarlosEDP has joined #riscv
frost has joined #riscv
khem has joined #riscv
pierce has joined #riscv
psydroid has joined #riscv
kaji has joined #riscv
BOKALDO has joined #riscv
pecastro has joined #riscv
EmanuelLoos[m] has joined #riscv
pecastro has quit [Ping timeout: 248 seconds]
hendursa1 has quit [Quit: hendursa1]
hendursaga has joined #riscv
adomas has joined #riscv
SpaceCoaster has joined #riscv
SpaceCoaster has quit [Remote host closed the connection]
<xentrac>
solrize: oh, I hadn't updated the text dir (without .git) in months. I should set up a hook to do that
<xentrac>
something like sweet16 on the avr is definitely worth it if you're talking about one of the avrs with 2k or 4k or probably 8k of flash. for bigger avrs it depends on what you're doing
<xentrac>
lisp as such is maybe a harder sell
jedix has quit [Ping timeout: 248 seconds]
jedix has joined #riscv
zjason has quit [Ping timeout: 268 seconds]
compscipunk has joined #riscv
frost has quit [Quit: Connection closed]
iorem has joined #riscv
<solrize>
xentrac, currently using a 16k avr because there is about 9k of code and it overran the more common 8k version. it can be debloated some but if sweet16 can get it way below 8k that is great. do you know if there is a C compiler backend for sweet16 or similar? i wonder how much sweet16 was designed around the 6502 and if things should be a little different for the avr. the super cheap padauk parts (well probably the "expensive" 10 cent one) are another t
<solrize>
arget of interest maybe
aburgess has quit [Ping timeout: 256 seconds]
<sorear>
why not just have a little more decode logic and do something like that in hardware
<solrize>
do what, run a 16 bit instruction set on an 8 bitter?
<sorear>
not necessarily a full one
<solrize>
i wonder if it might be possible to reorganize the code to get rid of most of the memory accesses since the avr has so many registers. that would squish the code down
<sorear>
but yes, register-pair 16 bit ops
<solrize>
the avr does have some of those... i think maybe the point of sweet16 is making 16 bit memory pointers less cumbersome and this program doesn't need that. it can probably get by with 256 bytes of ram
<solrize>
not counting the hardware stack and maybe a few arrays
<solrize>
sweet16 predated the arm by many many years ;)
<xentrac>
no, only about 8 years
<solrize>
certainly implementing sweet16 on an avr is easy enough, so it's more a question of compiler target
<sorear>
yes, but it wasn't controlled by a bit in the status register
<xentrac>
but I guess it predated Thumb by about 14 years
<xentrac>
yeah, and sweet16 is not an appealing C compiler target
<solrize>
hmm i didn't realize
Gravis_ is now known as Gravis
<xentrac>
the Excel group at Microsoft actually did what we're talking about, but their emulators ran on 8086 and 68000, not AVR and PDK14
iorem has quit [Quit: Connection closed]
<solrize>
i am still a bit puzzled why there is so much code in this app... i look at it and it all seems there for a reason and there is no really serious bloat but it seems like a lot of code for a flashlight
<solrize>
i wonder what the photon freedom has
<xentrac>
they wrote a C compiler that compiled to a bytecode that enabled them to fit a lot more Excel functionality into the tiny computers of the 80s
<xentrac>
precisely opposite from my expectations, AVR is looking like a less unreasonable platform now than in the years before the Microchip acquisition
<solrize>
hmm interesting any idea what the bytecode format was?
<xentrac>
they're releasing a bunch of new chips
<solrize>
avr has always seemed kind of nice to me despite not being that attractive for C. but, it is kind of expensive, so i wonder who buys it
<xentrac>
(hmm, is there a reasonable way to define a 16-bit version of RISC-V?)
<solrize>
there are some mailing list messages about 16 bit risc-v that got linked here some time back
<xentrac>
AVR is kind of okay for C but you will bletch if you look at how it compiles int x = y << 4;
<solrize>
i think the idea never went anywhere
<solrize>
are there nibble instructions?
<solrize>
idr
<xentrac>
nope
<solrize>
ic, not a traditinal 8 bitter then ;)
<solrize>
did excel run on 8 bit machines? or just pc/mac
<xentrac>
there were lots of PCs that were 8-bit machines, but no, just Mac originally, which was architecturally 32-bit
<xentrac>
then later the 8086
<solrize>
well 8088 was architecturally 16 bit pretty much
<xentrac>
yeah, exactly
<xentrac>
same thing
<xentrac>
at some point I had found out the name of the Excel bytecode language but I'm not finding it now
<solrize>
it had segmented addressing and pc's normally had >= 256kb of memory i thought
<solrize>
mac started at 128kb
<xentrac>
my first PC had a Z80 and 48K of RAM
<xentrac>
the Mac was a PC too, arguably the most personal of all
<xentrac>
the IBM PC 5150 shipped with 64K
<xentrac>
you could run BASIC on it. or rogue.
* rjek
's had a Z80 and 1kB :D
<sorear>
multi-width shifts kind of suck
<solrize>
i mean ibm 8088 pc, ok if they had 64k and ran excel that constarined excel
<solrize>
8088 had multi-bit shift instruction though it was serial and slow
<sorear>
nice thing that MS was able to change all the FAR pointers to linear 32 bit addresses and keep most of the structs compatible, so you could mix 16 and 32 bit code in a process
<xentrac>
I don't think Excel could ever run in 64k. multiplan maybe
<sorear>
the 8088 was an 8086 with a different bus interface unit
<solrize>
64k really seemed like a lot
<xentrac>
Excel didn't ship for the 8086 until 01987
<xentrac>
I don't think they ever released the compiler though so it wouldn't be practically useful for this. I think I might have found some information about the bytecode format at some point
<xentrac>
but, yeah, implementing a simple 16-bit instruction set in AVR assembly (or PDK14 assembly or PIC assembly) and compiling C to it seems like a clearly good idea for non-performance-critical parts of embedded programs, because you could probably get a significant code density improvement. there are lots of interpreters for compact code for tiny 8-bit computers but none that I've seen that have a C compiler
<xentrac>
targeting them
<rjek>
zcode, anyone?
<rjek>
Or Pascal pcode machines
<sorear>
what would you target? pdp11? 16-bit m68k?
<rjek>
ARM, except compressed, which ends up denser than Thumb (v1) anyway
<rjek>
(And performs better if you demand-page and decompress it)
<solrize>
well you want the interpreter to be very simple like sweet16's or else it takes up too much code space in its own right
<xentrac>
dunno. maybe the simplest thing to do would be to take bcc, openwatcom, or the digital mars C compiler, and implement just the 8086 opcodes their backend actually emits
<sorear>
(being familiar with the encoding I suspect m68k would take a smaller penalty for mixing 16 and 32 bit accesses than 386 or arm, although a benchmark would be needed to confirm this)
<solrize>
sweet16 6502 interpreter was supposedly 300 bytes
<solrize>
what are those compilers? are they FOSS? is something wrong with gcc?
<sorear>
tru
<xentrac>
yeah, it was. you can read the listing
<xentrac>
gcc isn't very good at generating 8086 code, historically
<solrize>
8086 had all kinds of awful special registers
<rjek>
LCC + quake 1's VM? :D
<solrize>
i didn't realize it ever targeted 8086
<xentrac>
yeah, all three of those compilers are free software
<rjek>
sdcc too ("small devices")
<xentrac>
it didn't use to, solrize
<sorear>
sdcc does not have a great reputation for optimizations or actually following the C standard
<xentrac>
I don't think sdcc supports 8086. maybe it supports some other 16-bit architecture?
<solrize>
oh interesting about the compilers. i do know about sdcc. but i think it's fine to have a good format and target a compiler to it, rather than trying to emulate an existing insn set
<solrize>
gcc supports msp430
<sorear>
although for the chips sdcc primarily targets you don't have good options
<solrize>
but i mean 8086 is the last thing i'd want to emulate
<xentrac>
an 8086 subset might be okay
<xentrac>
like, emulating the status flags all the time is gonna suck
<xentrac>
but if you have a simple compiler backend that only ever uses them with patterns like test;jcc or cmp;jcc then it would be reasonably easy
<solrize>
i think it is just not worth trying to be compatible with some crappy old cpu and i think it is ok for the bytecode to fit the status flags of the target cpu
<solrize>
but, question is, is there going to be real code density gains for programs that are really mostly 8 bit?
<xentrac>
no, but lots of programs are mostly 16-bit
<solrize>
like there are not many 16 bit arithmetic operations in this flashlight program and it doesn't need 16 bit ram pointers. it does need 16 bit code addresses though, or anyway 14 bit
<xentrac>
especially if they're written in C, which silently coerces things to ints at the drop of a hat
<solrize>
the relevant cpus rarely have more than 1k of ram
<solrize>
sweet16 was for the comparatively large apple ii
<xentrac>
yeah
<xentrac>
I didn't realize about msp430, thanks for that news
<sorear>
what does a "flashlight program" do
<solrize>
controls a flashlight, so you can set it to different brightnesses, flashing modes, has temperature and battery voltage monitoring etc
<solrize>
it will be a lot more if a USB comm stack and li ion charge control is added, i think
<xentrac>
what does it do with the temperature and battery voltage?
<sorear>
I see a lot of outlining opportunities
<solrize>
it does seem like more code than should really be needed, but looking at it there is no awful bloat
<solrize>
dims the light if it gets too hot or if the battery gets low, shuts off if battery gets way low to prevent over-discharge
<solrize>
that is required for safety
<xentrac>
true
<xentrac>
unless you have an external BMS chip which probably is the equivalent of more than 9k of code
<sorear>
like there are 8 instances of pseudo_rand() % NUMBER. AVR doesn't have div/mod so that's already 2 calls, just make NUMBER an argument
<solrize>
it's a flashlight and all the electronics have to fit on a circular pcb same diameter as the battery
<xentrac>
why would you want random numbers to set flashlight brightness?
<solrize>
it has a mode that simulates a flickering candle
<xentrac>
that sounds like a bloated way to implement that
<solrize>
it has exponential ramping for brightness using a table lookup but it occurs to me, a random process might be another way to do that
Andre_H has joined #riscv
<xentrac>
or a loop
<solrize>
yeah i dunno, i haven't looked at that part much, but i don'tthink it accounts for that much of the code
<solrize>
the ramping code is fairly bloaty
<sorear>
i don't really get what all the events are for but I've only looked at this for a few minutes
<solrize>
but there isn't any one place you can point to and say "omg you used printf that's 3k of code right there" eg
* sorear
expected some sort of cyclic executive
<xentrac>
you can get a pretty reasonable flicker out of something like t ^ (t + t >> 6)
<solrize>
i dunno i might try
<solrize>
i have seen led candles and they are really convincing imitations of real candles
<geertu>
xentrac: make sure you never reach t = 0 ;-)
<xentrac>
geertu: it's okay for the flicker to have a moment of darkness, isn't it'?
<solrize>
events: there are pushbutton events, timer events, dunno what else really since i guess stuff like temperature monitoring would be done on timer ticks
<xentrac>
or you could do a running sum
<solrize>
it would be a very long moment of darkness if t=0 :)
<sorear>
why not just a loop with if (X pressed) { do things for X }
<sorear>
without creating and then subsequently decoding an event
<xentrac>
sorear: right
<xentrac>
solrize: why a very long moment of darkness? t = 0 only for a very short time
<solrize>
well pushbutton is detected in a timing loop so switch bounce doesn't count as multiple presses
<solrize>
oh it goes from 0 to -1 sorry
<sorear>
but again I've only looked at it for 10 minutes and "reorganize the whole thing" is not a helpful urge
<xentrac>
I dunno, it seems like a pretty interesting project actually
<solrize>
yeah i dunno. i know someone did a thing like this (closed source) in PIC assembler some years back, it was much less fancy and it hit the limit of the code space in that pic
<xentrac>
how much of a flashlight program can you get working in 64 instructions? 128? 256?
<solrize>
but that might have been 1k or 2k or something (pic words = equivalent to maybe 2 bytes each)
<sorear>
why are you limited to 8kB on a PCB the diameter of a battery? flash bit cells are not that big
<solrize>
no idea
<solrize>
need a part with a small package
<xentrac>
sorear: AVR went a lot of years without a real update
<solrize>
i mean no idea about 256 instructions, maybe just basic on/off/1 or 2 brightness levels
<solrize>
maybe enough for some very basic low power lights that don't overheat or explode if you don't watch the temperature and battery
<sorear>
is there a public schematic?
<solrize>
for this light? i dunno i will ask. but there are some similar ones around that probably do have public schematics
* sorear
kind of prefers not having software in the loop for safety critical feedbacks, but the board size may be an issue
<xentrac>
like the ATMega168 came out in 02004 or so? and then the ATMega328 in like 02006? and then nothing until 02018
<solrize>
it's not super complicated, there is a dc-dc converter (that is another thing that the cpu could potentially control) and the mcu uses pwm to control the led brightness
<solrize>
xentrac, i think there were other avrs through that whole period
<xentrac>
solrize: yeah but they were all stuck with a slow ADC, tiny memory (or huge expensive package), and 20MHz
<xentrac>
yeah, you could generate the buck converter waveform on the CPU too
<xentrac>
ooh nice
<sorear>
battery connected to LED stack via DC/DC, MCU connected to a pushbutton and the DC/DC's enable inputs?
<xentrac>
thanks!
<solrize>
there are multiple leds on separate pwm channels
<sorear>
Not sure if a full set of buck converter passives would actually be smaller than some of the integrated DC/DCs you can buy these days
<solrize>
wouldn't the integrated dc/dc need the same passives?
<solrize>
these are powerful lights, like 5+ amps in some cases
<sorear>
yes but they're 3 dimensionally integrated, not taking up PCB footprint space
<solrize>
hm ok
<xentrac>
solrize: that still sounds like if (pwmt < pwma) PORTB |= 1; else PORTB &= ~1; if (pwmt < pwmb) PORTB |= 2; else PORTB &= ~2;
<sorear>
The full LED current is routed through the MCU PWM drivers, with the DC/DC merely providing a constant voltage supply?
<xentrac>
like 4 instructions per extra PWM channel
<xentrac>
surely not
<sorear>
how does the temperature management work, is there a component for that?
<xentrac>
though a standard buck converter running off a battery provides a constant voltage source, not a constant current source. so you need a separate PWM transistor
<solrize>
sorear, i'm not sure how the dc/dc is set up but i think some of the #flashlight regulars do know about it. there may be temp monitor on the chip or maybe there is an on board thermistor, idk
<xentrac>
(I know you *said* it provided a constant voltage supply)
<solrize>
idk if it is constant voltage either. in some other lights (not this one) it is adjustable constant current so you can dim the light without pwm flicker
<xentrac>
I mean that's what buck converters do
<xentrac>
an unregulated buck converter's output voltage changes very little with the load except at very low loads
<xentrac>
are the different LEDs on different channels because they're different colors?
<solrize>
there is an auxiliary led for the backlit pushbutton
<xentrac>
ah
<solrize>
in some cases that is an rgb led
<xentrac>
but yeah ideally you want a constant-current SMPS. is there a design for that out there? I tried designing one but wasn't successful
<solrize>
i think there are designs, someone on #flashlight gave me a link, want me to find it?
<sorear>
and you want to add an entire USB stack to this?
<solrize>
sorear, usb comms would be nice, so you can just plug in a usb cable instead of needing a special weird dongle. and for the bigger lights it would be good to support usb-pd power delivery for fast charging. also device-to-device so you can use the light as a power bank
<xentrac>
sure, if you have it handy!
<sorear>
you are not going to support USB PD in a device with 8 kb of coded
<xentrac>
sorear: it's that bad?!
<solrize>
yes right, thus the code is going to get a lot bigger
<solrize>
but in a light that big there is more space available
<xentrac>
"flashlight firmware" sort of seems high on the list of "projects that you should not do if your goal is to impress people"
<xentrac>
because evidently it is much more difficult than it appears
<xentrac>
and if you show nontechnical people they will be very unimpressed
<solrize>
xentrac, almost any interesting software is harder than it appears ;)
<solrize>
i think usb pd is not a megabyte of code, but it is a lot. there is an implementation on github
<xentrac>
solrize: it can be personally advantageous to find the exceptions and focus your work on those
<solrize>
lol After Snowden exposed old backdoors, they need new. But there is budget cuts, so they hired interns who knows only node js.
<solrize>
i'm pissed as hell because i bought a super expensive flashlight some years ago, and it turns out to have excessive parasitic current (battery drain when turned off) because of a firmware bug, and it's closed source so i can't fix it myself. so i'm completely keyed up for gpl3 flashlight firmware.
<xentrac>
I just keep thinking of a bent strip from an aluminum can bridging a lightbulb to a battery ;)
<solrize>
also (maybe this is a little bit more on topic for riscv) the pinecil soldering iron has a gd32vf processor and i think it must use usb pd
<solrize>
that part has 128k of code space iirc
<solrize>
gd32vf103
<sorear>
you need _something_ to act as a ballast for the LEDs and a resistor is kind of meh for a multi-watt flashlight
<solrize>
i guess the soldering iron is equivalent to a sufficiently powerful flashlight ;)
<solrize>
so i wonder if the code isavailable
<solrize>
but it doesn't run on batteries, it relies on the usb pd
<solrize>
i guess a big flashlight running off a usb pd powerbank would be ok
theruran has quit [Ping timeout: 258 seconds]
panzeroceania has quit [Ping timeout: 240 seconds]
SanchayanMaity has quit [Ping timeout: 245 seconds]
panzeroceania has joined #riscv
SanchayanMaity has joined #riscv
<solrize>
any idea what packages the GD32VF103TB is available in? why does the pinecil page say "chipset" instead of "chip"?
<solrize>
hmm QFN36 it looks like
<solrize>
5x6mm i guess that is ok for an 18mm light
panzeroceania has quit [Ping timeout: 258 seconds]
panzeroceania has joined #riscv
theruran has joined #riscv
theruran has quit [Ping timeout: 248 seconds]
theruran has joined #riscv
SanchayanMaity_ has joined #riscv
panzeroceania_ has joined #riscv
SanchayanMaity has quit [Ping timeout: 248 seconds]
SanchayanMaity_ is now known as SanchayanMaity
panzeroceania has quit [Ping timeout: 248 seconds]
panzeroceania_ is now known as panzeroceania
SpaceCoaster has joined #riscv
SpaceCoaster has quit [Remote host closed the connection]
mahmutov has quit [Read error: Connection reset by peer]
mahmutov has joined #riscv
nvmd has joined #riscv
<xentrac>
sorear: yeah, you can definitely control a buck converter running off a battery to deliver constant current, rather than constant voltage, with feedback
<xentrac>
my attempts to design such a circuit met with failure, but that's just because I'm shitty at analog design I think. thinking about it now it sounds easy
<xentrac>
in simulation even
aburgess has joined #riscv
<xentrac>
a constant-voltage buck converter doesn't require any feedback, just a constant duty cycle and enough load to stay in CCM, but I'm not sure the circuitry for constant-current control is actually any more complicated than the oscillator
scruffyfurn_ is now known as scruffyfurn
BOKALDO has quit [Quit: Leaving]
winterflaw has quit [Remote host closed the connection]
Andre_H has quit [Ping timeout: 258 seconds]
winterflaw has joined #riscv
Narrat has joined #riscv
winterflaw has quit [Ping timeout: 244 seconds]
Andre_H has joined #riscv
Andre_H has quit [Quit: Leaving.]
pecastro has joined #riscv
<solrize>
does anyone here use protothreads? it relies on the __LINE__ cpp macro, but the program i think of using it in #includes a bunch of other .c files, so __LINE__ could end up collding
<solrize>
*colliding
<xentrac>
you can use __FILE__ too
pecastro has quit [Ping timeout: 272 seconds]
<xentrac>
I mean I haven't used protothreads but I understand how it works
<xentrac>
I have to say though that #including a .c file in the middle of a function is an unusual thing to do ;)
adjtm_ has quit [Ping timeout: 268 seconds]
adjtm has joined #riscv
pecastro has joined #riscv
aredridel has joined #riscv
<solrize>
not in the middle of a function, just in the middle of another file
<solrize>
idea is to get all the code in one file so gcc can do whole-program optimization
pecastro has quit [Quit: Lost terminal]
<xentrac>
I'd think collisions in resumption points between functions wouldn't be a problem
devcpu has joined #riscv
<solrize>
hmm maybe not
<jrtc27>
if you don't care about Windows there's __COUNTER__ as a GNU extension
<jrtc27>
(implemented by both GCC and Clang)
<jrtc27>
(... and presumably clang-cl if you do care about Windows?)
<solrize>
hmm interesting i didn't know about __COUNTER__. not worried about windows
<xentrac>
for protothreads worrying about Keil is more likely than worrying about Windows
valentin has quit [Quit: Leaving]
devcpu has quit [Ping timeout: 258 seconds]
devcpu has joined #riscv
Narrat has quit [Quit: They say a little knowledge is a dangerous thing, but it's not one half so bad as a lot of ignorance.]
jedix has quit [Ping timeout: 248 seconds]
jedix has joined #riscv
dermato has quit [Ping timeout: 268 seconds]
djdelorie has joined #riscv
dermato has joined #riscv
djdelorie has quit [Remote host closed the connection]