
Fresh IDE - mutin-sa
https://fresh.flatassembler.net/
======
truncate
Just curious if they wrote the IDE in assembly (my instincts say not, but they
do make assembler). The login is giving 404
[https://fresh.flatassembler.net/fossil/repo/fresh/fossil/rep...](https://fresh.flatassembler.net/fossil/repo/fresh/fossil/repo/fresh/login)

~~~
2ton_jeff
The IDE is indeed written entirely in assembly language, as is everything from
the webserver up (JohnFound, author of FreshLib/FreshIDE also wrote a fastcgi
layer to interconnect with rwasa from my own goods). Everything there is
assembler.

~~~
zerr
This is not the assembly we remember from TASM/MASM days though. It seems to
include quite many high level constructs.

~~~
2ton_jeff
fasm was in fact modelled after early TASM, and much of the "high level
constructs" are just macros... or did you mean something more specific?

~~~
wruza
At the time I lost my interest to assembly, it had pretty high-level contructs
like looping, function frames, structs, etc. via macros. Macros of fasm are
iirc recursive, so its power is far more than usual assembler. I would put it
at 85% on [regular asm .. non-optimized C] scale. You can think of tasm/masm
as of lisp with cpp instead of macros.

The use case beyond educational purpose is still unclear to me though.
Especially _with_ macros.

~~~
pjmlp
Actually the only Assembler I got disappointed with bare macros support is
gas.

I never used FASM, being an old MS-DOS grey beard, but tasm/masm macros were
quite powerful, specially after MASM 6.0.

So I never got the idea they were like cpp macros.

Regarding the educational purpose with macros, are you aware that TI has some
CPUs with an Assembler that looks like C--, or that AS/400 Assembly supports
objects?

~~~
mhd
Back in the day, there was a bit of a hierarchy amongst home computer users,
with Amiga assembly programmers deriding x86 syntax.

I also knew a few people who nominally programmedi in Turbo Pascal, but whose
code was 70% inline assembly...

And weirdly enough, a few marooned Acorn Archimedes/RiscPC programmers waxing
poetic about their ARMs.

(And if there ever was some niche of a "MenuetOS"-like OS, it would probably
be for the Raspberry Pi)

~~~
pjmlp
Yeah, looking back I would say Turbo Pascal, Turbo C, Turbo Basic and AMOS on
Amiga were the Unity of the early 90's game dev on home computers.

Anything that actually required extracting performance out of the system was
straight Assembly, which I why it is ironic that new generations think that C
compilers were generating fast code since day one.

I also knew a few people that did it like that, to save money on an Assembler.

------
dguaraglia
Oh boy, the memories from all the "IDEs" there were for NASM. In the end, it
was just easier to use your favorite editor, because most of them just had a
pretty color scheme for assembly. This looks pretty sweet, though.

~~~
baldfat
AS a kid I remember those days. I spent like $100 because the IDE was going to
help me crack all the gamez. Whelp that was a sorry waste of money.

~~~
dguaraglia
Haha, I managed to crack a couple programs by following the +ORC cracking
tutorials and a (cracked, of course) copy of SoftICE. In fact, that's how I
got interested in assembly. Then I learned C and started using Linux as my
operating system, so I didn't have a need for either thing anymore :/

------
kitd
I like the example project that compiles a source file into a Mandelbrot
image.

------
ungzd
I don't know what are use cases for that. Nowadays, if you are coding in
assembly, you are probably doing some kernel things, embedding asm in C/C++
(for SIMD or something like that and not because compilers generate bad code),
embedded code for microcontrollers or retro computers (i.e. ZX Spectrum).

But Visual Studio-like IDE for making x86 application software, with GUI
editor seems weird.

~~~
johnfound
I am using assembly language for all my programming tasks.

And most of they are application programming (Fresh IDE itself and many closed
source projects in my work) or even web programming
([https://board.asm32.info](https://board.asm32.info)).

That is why I needed a powerful IDE, suitable for rapid programming of
relatively big projects (500Kloc or higher).

~~~
osrec
This is interesting. Do you not find the dev process significantly slower than
using a higher level language?

~~~
johnfound
About twice slower than in HLL, with code reusing of course.

But the code is more reliable and the debugging process is much easier. After
some short debugging stage, most of the projects runs for years without single
bug report or other support issues.

I am not talking about the significantly higher speed, lower memory footprint
and better UX (especially the response time of the UI is really much faster).

As a whole the advantages are more than disadvantages IMHO.

~~~
zoul
Interesting. Are you sure the increase in code reliability goes down to the
language and not your skills? It feels quite contrary to my experience that a
lower-level language would be more reliable.

~~~
johnfound
Well, I am pretty average programmer. Not the worst, not the best.

The code reliability of assembly programs is better because programming
algorithms in low level, the programmer controls every aspect of the
execution. Notice, that excessive use of __code generation __macros will
cancel this advantage.

Another advantage is that the bugs in assembly programs usually cause
immediate crash of the program and this making the fixing easy.

Defer crashes and strange/random/undefined behavior of bugs in assembly
programs is rare. IMO, this is because of reduced count of abstraction layers.

~~~
osrec
What about code maintainability and readability - I'm guessing that must be
worse when compared to a HLL? Also, what made you get into writing complex
programs in assembly - was it just the extra control? I've used assembly when
I needed to optimise my C code, but it was a slow and difficult process! I
would not really choose it for complex stuff, but I'm really interested to
hear your point of view.

~~~
johnfound
Code maintainability and readability depends only on the programmers knowledge
of the language/framework/libraries used.

For example, I don't know Lisp, so for me it is much harder to read/maintain
Lisp project than assembly language project.

------
jerianasmith
With too many high level constructs, i also feel it looks quite different from
TASM days.

------
TylerE
It would make a better first impression if your hero screenshot didn't have
font rendering from circa 1995.

~~~
Uehreka
I know that comment seems superficial, but when I saw the Windows 98 style
GUI, I actually thought that perhaps this was an abandoned project someone was
bringing up for nostalgic purposes.

~~~
johnfound
The screenshots are taken in Linux: XFCE+Wine. Fresh IDE is actually some kind
of hybrid application. It works in Linux better and with more features than in
Windows. :)

~~~
rbanffy
I know Windows is a lost cause, but Unix apps don't have to be ugly like that
;-)

And even Windows can use GTK.

~~~
johnfound
I am working on v3.0 that will use its own portable GUI toolkit (in assembly
language) with much prettier UI. On this page you can see some preliminary
experimental screenshots:
[https://fresh.flatassembler.net/index.cgi?page=content/artic...](https://fresh.flatassembler.net/index.cgi?page=content/articles/5_FreshLibGUI.txt)

Still not GTK though. It is too heavy for assembly language programming and
will not allow portability for example on MenuetOS or KolibriOS assembly
written OSes.

~~~
vanderZwan
Nice improvement! The screenshots have much nicer font rendering (and a better
font, for that matter). The fact that it uses more than the 16 colours that
were available in Windows 3.1 helps a lot too.

------
shash7
On a side note, check out how they have laid out the curved screenshot.

It is apparently a stack of images. That helps setting the text to follow the
couture of the curve.

~~~
Klathmon
There's actually a CSS property just for this called `shape-outside` [0].

It lets you define a shape of an image (or other element) that makes it so
when it is floated, other elements can wrap up against it correctly.

[1] is an example I just quickly made to show how the linked page could have
been done in straight CSS. It works a bit nicer too as the text smoothly wraps
instead of stepping like the linked article does (although there is no reason
why both methods can't be combined to provide a smooth stepping where
possible, and fallback to the approximation they used when it's not supported)

It's browser support is pretty awful right now (only chrome, safari with the
`-webkit` prefix, and basic support in firefox behind a flag), but if it makes
it to standardization, it's a pretty neat tool to be able to reach for in
these cases.

If there were an easier way to see if the website itself was open source, I'd
try and give it as a quick patch, but it doesn't look like the website itself
is open source anywhere that I can find.

[0] [https://developer.mozilla.org/en-US/docs/Web/CSS/shape-
outsi...](https://developer.mozilla.org/en-US/docs/Web/CSS/shape-outside)

[1] [https://jsfiddle.net/c1ffdpgq/2/](https://jsfiddle.net/c1ffdpgq/2/)

~~~
TremendousJudge
Your example doesn't work in Firefox (text doesn't wrap properly), but it does
in Chrome

~~~
Klathmon
On desktop firefox you need to enable a flag in the browser for it to start
working (at least that's what MDN says, I didn't try it)

------
chrisparton1991
The HTTP response code for fresh.flatassembler.net assets is "200 She'll be
apples", I didn't know 200s could be customised like that :)

~~~
2ton_jeff
Hahah, proper Aussie mate! (there's a compile-time flag to make them all
boring instead of our homage to Aussie slang haha, cheers and glad you like
it)

~~~
exikyut
Hi! I thought the response string was rwasa's fault :)

Question. I've just started to become interested in learning/messing around
with assembly language under Linux, and fasm seems like a really attractive
option - as and nasm are both tied to gcc (nasm indirectly), and fasm skips
all that (and produces slightly smaller binaries too!). fasm also seems
compiles itself in less than a second on my really old machine as well, and
fast iteration time is one of my favorite features.

Linux-specific assembly-language documentation is kind of rare on the ground
though; for fasm in particular, there's literally hens' teeth and dust
bunnies. It's very possible to piece things together, but if you have
absolutely no idea what you're doing it's a bit intimidating.

HeavyThing is practically a tutorial in and of itself, but I must admit my
hesitancy to lean too heavily on it due to its use of GPLv3. I certainly
respect the use of that license (and understand the many reasons it might be
used for such a unique project), but I'm only tinkering around myself at this
point so would likely want to use MIT, CC0 or similar, and would feel a bit
conflicted about the predominant thing I learned from being from GPLv3.

HT is on the list for sure, but I wanted to combine it with other sources of
info. You seem to be one of the few people out there actively using fasm for
Linux development, so I figured it couldn't hurt to ask if you had any other
high-level suggestions.

~~~
2ton_jeff
Start simple and hook fasm in with a "normal" gcc/g++ project... I wrote a
page[0] ages ago on integrating C/C++ with the HeavyThing library and a good
portion of that has nothing to do with my library specifically and is a great
starting point to mess around with assembler on a Linux platform. The only
other pointer is the "call PLT" format for calling externally linked functions
from inside your fasm objects but that is the only tricky bit IMO.

[https://2ton.com.au/rants_and_musings/gcc_integration.html](https://2ton.com.au/rants_and_musings/gcc_integration.html)

~~~
exikyut
That makes a lot of sense.

I could combine this with viewing gcc's assembly output, as well!

Thanks :D

Edit: This page is ridiculously comprehensive. Wow.

~~~
gens
The official fasm tar comes with a few hello world examples. One shows you how
to say hello with libc, other with the kernel (then there's x86 and amd64
versions of bout).

[http://chamilo2.grenet.fr/inp/courses/ENSIMAG3MM1LDB/documen...](http://chamilo2.grenet.fr/inp/courses/ENSIMAG3MM1LDB/document/doc_abi_ia64.pdf)
is the official spec for the amd64 calling convention (aka ABI) on unices.
[http://www.logix.cz/michal/devel/amd64-regs/](http://www.logix.cz/michal/devel/amd64-regs/)
is a nice table showing what goes in what register (still amd64) when calling
a C library or the kernel. X86 library calling convention is just putting
everything on the stack, while the kernel convention.. i don't remember (int
80 and syscall in eax, but arguments..). There's a syscall table
[https://filippo.io/linux-syscall-table/](https://filippo.io/linux-syscall-
table/) and i made a fasm to include
[https://pastebin.com/nnrMVF8u](https://pastebin.com/nnrMVF8u) (amd64; i made
from the kernel source headers, that i can't find now).

That's about all there is linux specific.

~~~
exikyut
Hmm, interesting.

I've had a look at the examples that come with fasm, which are invaluable.

But I _completely_ forgot to point out (I knew I was forgetting something!) in
my previous comment that I'm actually looking for info on _32-bit_ assembly
programming. My motivation comes from the fact that a) a lot of my systems are
32-bit (such as the ThinkPad T43 I'm using to type this), due to circumstances
I cannot change; and b) because (as I discovered to my delight) a program
written for i386 and statically linked (eg, by fasm's ELF writer) will run on
x86_64 without 32-bit glibc/userspace/anything! This makes perfect sense, but
is an absolute winner for me for the kinds of things I'm going to want to
make.

So x86_64 is in the "it would be monumentally stupid not to learn it"
category, and I'm looking forward to doing so, but I'd have to do some
_serious_ ly inelegant wrangling (something like qemu-x86_64 + 64-bit
userspace - on a 32-bit machine, lolol) to actually work with it at this
point.

The syscall table you made is very similar to HeavyThing's, heh. I've actually
been researching precisely that of late; you most likely generated your copy
from
[https://github.com/torvalds/linux/blob/master/arch/x86/entry...](https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_64.tbl).
I of course want
[https://github.com/torvalds/linux/blob/master/arch/x86/entry...](https://github.com/torvalds/linux/blob/master/arch/x86/entry/syscalls/syscall_32.tbl).

~~~
gens
amd64 is just an extension on x86. I took the (64bit) syscalls from a kernel
header, that i can't find now, so you can take from that header you found.

C calling convention for x86 is to push everything on the stack (and use call,
that is short for "push instruction pointer and jmp", ret being the reverse),
while the linux kernel uses a variant of fastcall (aka put stuff in registers
(then use int 80)).

When i was learning i found a lot of x86 examples and tutorials (and a book,
can't remember the name (is free)), and not much on amd64.

Just play with it, it'l get easy when you go over the wall.

With "normal" C calling convention you have to care about the stack pointer
(esp) (i think it's the callee's responsibility (of the called function)),
maybe even the bottom pointer (ebp) (i remember the wikipedia page on calling
conventions explains it). The other difference between x86 and amd64 is
floating point math, where sse is the default on amd64 and x87 on x86 (x87
works on stacks of numbers, the reverse-polish using a stack way IIRC).

Useful tools are: objdump -d ("-M intel" for the intel notation), strace to
trace system calls, and fdbg since GDB can't make sense of a valid ELF file.
You can also join the flat assembler and/or nasm forums. I like fasm better
then nasm for no strong reason, but nasm _is_ a bit easier.

glhf

