The AmigaOS3.2 development team has set up the AmigaOS Development BLOG, the goal of which is not to provide insights into the current development of the OS, but rather to assist in getting started with AmigaOS programming. This blog is intended to provide a series of articles that will cover installation of development tools, programming examples, debugging issues, and other helpful tips.
The first two posts will deal with installing/using the NDK with the SAS/C and VBCC compilers.

https://aosdg.blogspot.com/

_________________
AmigaNG, YouTube, LeaveReality Studio

@amigang

Wonderful!

_________________

A BLOG! Of course. How have we been so blind this whole time when the solution was staring us in the face all along.

Don't get me wrong. I appreciate that there are developers that are willing to publicly share their experience, but I think their efforts would be better served in making it possible to use 21C dev languages, frameworks, and tools applicable to Amiga, instead of perpetuating dev practices from a generation ago.

At this point it feels like the last two surviving male Egyptian Leopards starting a blog about good mating practices.

_________________
All the way, with 68k

@agami

Quote:

agami wrote: A BLOG! Of course. How have we been so blind this whole time when the solution was staring us in the face all along. Don't get me wrong. I appreciate that there are developers that are willing to publicly share their experience, but I think their efforts would be better served in making it possible to use 21C dev languages, frameworks, and tools applicable to Amiga, instead of perpetuating dev practices from a generation ago. At this point it feels like the last two surviving male Egyptian Leopards starting a blog about good mating practices.

Please keep in mind that this is still a very modest platform with regard to processing power, available memory and overall scalability. Dragging it kicking and screaming into the 21st century is not a option without teaching it to be the kind of thing it really isn't.

If recent reports about an AmigaOS-native gcc 6.5.0 compiler are true, you cannot even run it decently on the Amiga itself owing to its size and how poorly the Amiga file system handles executables that large.

This is not a modern operating system, although it arguably is still more modern than its peers used to be. It is designed to make the most of its modest origins and capabilities of the hardware of the age. These aspects do not go away over time, but the constraints baked into the design make themselves felt more strongly. As it is, software and hardware designed for AmigaOS have to be aware of the constraints in order to work well.

I expect a C2X compiler for the Amiga not to be viable as a native development tool, and try as you might, the complexity is a problem here. Modern operating systems shrug this off, having more memory and a much more powerful mass storage and file I/O system to cope with that. The AmigaOS has none of the latter.

Funny enough, a native gcc 2.95.3 still is a viable Amiga 'C' and C++ compiler. And the older SAS/C 6.5 runs rings around it and delivers production quality code, too.

You might expect more and are right to expect more, but opening up what was constrained for so long is a challenge indeed

@olsen

Quote:

olsen wrote: @agami Please keep in mind that this is still a very modest platform with regard to processing power, available memory and overall scalability. Dragging it kicking and screaming into the 21st century is not a option without teaching it to be the kind of thing it really isn't. If recent reports about an AmigaOS-native gcc 6.5.0 compiler are true, you cannot even run it decently on the Amiga itself owing to its size and how poorly the Amiga file system handles executables that large. ... You might expect more and are right to expect more, but opening up what was constrained for so long is a challenge indeed

I know. I'm sorry.
I am fully aware of the limitations of the classic Amiga hardware. I have been in the hardware and software game for most of my life. Also, when I say Amiga, I'm not just referring to classic hardware and OS.

I let my frustrations get the better of me, and for that I apologize.

Like I said, I appreciate that these developers are sharing their knowledge. And of course, they are free to use their talents in any way they see fit. I just hate to see what I consider to be a waste of talent on a archaic platform. Forgive me, but to me it would be like getting excited about someone starting a blog about COBOL programming on the IBM mainframe.

Not everyone has the potential to help move things forward, but it is very much a tragedy when you see those who can, spend their efforts on looking back.

_________________
All the way, with 68k

@agami

Did you even read the articles at all? they are useful, if not groundbreaking, not least because one of the most important things for ease of collaboration between developers whether on private or open source projects, is for everyone's development toolchain to be setup the same way.

_________________

@olsen

Sorry to hijack the thread, but it is relevant

Is there an issue with NewObject() and gcc with the latest NDK? It seems to complain it doesn't exist, and on further investigation it's something to do with brackets and ReAction macros. If I put extra brackets around everything it will build - but the resulting executable does not work.

eg, I need something like: (BitMapObject, GA_ID, 1, BitMapEnd);
It doesn't compile without the brackets - but doesn't work regardless.

Any ideas what might cause this?

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

olsen Quote:

Funny enough, a native gcc 2.95.3 still is a viable Amiga 'C' and C++ compiler. And the older SAS/C 6.5 runs rings around it and delivers production quality code, too.

Is that sarcasm? GCC 2.95.3 generates good quality integer 68k code. The problems with it are old support for C and C++ standards, old include files and less than impressive floating point support. It is surprisingly fast and doesn't use much memory when compiling on the 68k compared to vbcc but SAS/C is probably the best in that regard. SAS/C code generation quality is average at best but not bad considering how primitive the optimizations were back then. It is more outdated than GCC 2.95.3 but it is otherwise a solid compiler with few bugs remaining.

Chris_Y Quote:

Sorry to hijack the thread, but it is relevant

It's definitely on topic. The 3.2 NDK is more news worthy than the blog.

http://aminet.net/package/dev/misc/NDK3.2

These kinds of GCC problems are not fun to diagnose. Free bump for olsen help.

@matthey

Quote:

matthey wrote: olsen Quote: Funny enough, a native gcc 2.95.3 still is a viable Amiga 'C' and C++ compiler. And the older SAS/C 6.5 runs rings around it and delivers production quality code, too. Is that sarcasm?

No, sadness, really.

We are still using the best-integrated Amiga-native 'C' compiler designed to build the operating system with. And by "running rings around gcc" I literally mean how quickly the compiler loads, does its job and is ready for the next task.

We do daily builds of the entire operating system (from scratch) and it really makes a difference how quickly the compile .. compile .. compile .. link cycle/process completes for each component. gcc 2.95.3 is far larger than SAS/C (it has to be, owing both to its architecture, what it accomplishes and how it works) and that is one reason why we are not using it for production work.

Last edited by olsen on 19-Mar-2022 at 08:38 AM.
Last edited by olsen on 19-Mar-2022 at 08:13 AM.

@Chris_Y

Quote:

Chris_Y wrote: @olsen Sorry to hijack the thread, but it is relevant Is there an issue with NewObject() and gcc with the latest NDK? It seems to complain it doesn't exist, and on further investigation it's something to do with brackets and ReAction macros. If I put extra brackets around everything it will build - but the resulting executable does not work. eg, I need something like: (BitMapObject, GA_ID, 1, BitMapEnd); It doesn't compile without the brackets - but doesn't work regardless. Any ideas what might cause this?

What does "gcc -E" produce as output (which might be really hard to read, with all the macros expanded)?

It's possible that the helper macros for use with ReAction are vulnerable to side-effects with regard to how the compiler processes them. This may even be implementation-dependent (for the compiler being used and the 'C' language version). We found one such case for a ReAction program which did not compile "correctly" on vbcc because the order in which the macros were processed built the TagItem list in a different order than was the case for the SAS/C build.

This bears closer examination and it will be painful For the NDK 3.2 R4 I spent an awful lot of time "scrubbing" preprocessor macro definitions which were prone to side-effects. For the very first time ever I used JetBrains' "CLion" tool to produce hints as to what needed changing. Alas, no hints for the ReAction macros were given when I put it to good use...

@agami

Quote:

agami wrote: @olsen I let my frustrations get the better of me, and for that I apologize. Like I said, I appreciate that these developers are sharing their knowledge. And of course, they are free to use their talents in any way they see fit. I just hate to see what I consider to be a waste of talent on a archaic platform. Forgive me, but to me it would be like getting excited about someone starting a blog about COBOL programming on the IBM mainframe. Not everyone has the potential to help move things forward, but it is very much a tragedy when you see those who can, spend their efforts on looking back.

The Amiga is still a more modern operating system than you may give it credit to. It represent a "path not taken" in the grander scheme of things which we call progress in this domain.

You mentioned COBOL, which is, all things considered, an incredible achievement and a success story unlike anything else. This is "the path taken".

COBOL is also a 1950'ies design, which puts it into a very different time frame. The Amiga operating system is a 1980'ies design which, compared to its peer the Apple Macintosh operating system, shows how far you can go with its openness, transparency and extendability. Such a design can survive, grow and evolve if you let it.

It may never be able to catch up, but as the past has shown, it was able to put the gains provided by better CPUs and more memory into the hands of the user and the developer alike. On other contemporary platforms such gains were quickly consumed and "evaporated", which became a successful business model.

I would argue that the Amiga as a whole is an understandable and even humane design which you can scrutinize, criticize and learn from. The comparatively small scope (as compared to Linux or even Microsoft Window) and how well it has been mapped, make this possible. Amiga OS is not a toy operating system. One could learn lessons from it, if the documentation were better, though

This is one of my personal goals. There is much not well-understood about its design and implementation which is still worth exploring. The "paths not taken" often contain more lessons and inspiration than the technology which crushed them. The Amiga is one such thing, and so is the SmallTalk system, for example.

Last edited by olsen on 19-Mar-2022 at 08:40 AM.

@olsen

Is this the bit you want?

edit: aw.net doesn't like it, so here's a pastebin: https://pastebin.com/2r4Tcngw

I'm using modified macros:
Quote:

#define BitMapObj NewObject(BitMapClass, NULL #define LayoutVObj NewObject(LayoutClass, NULL, LAYOUT_Orientation, LAYOUT_ORIENT_VERT #define WindowObj NewObject(WindowClass, NULL

Original code is:
Quote:

win_obj = (WindowObj, #ifdef __amigaos4__ WA_ToolBox, TRUE, #endif WA_Borderless, TRUE, WA_BusyPointer, TRUE, WINDOW_Position, WPOS_CENTERSCREEN, WINDOW_LockWidth, TRUE, WINDOW_LockHeight, TRUE, WINDOW_ParentGroup, (LayoutVObj, LAYOUT_AddImage, bm_obj = (BitMapObj, BITMAP_SourceFile, "PROGDIR:Resources/splash.png", BITMAP_Screen, wbscreen, BITMAP_Precision, PRECISION_IMAGE, BitMapEnd), LayoutEnd), EndWindow);

Last edited by Chris_Y on 19-Mar-2022 at 02:37 PM.
Last edited by Chris_Y on 19-Mar-2022 at 02:36 PM.

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

The release notes in the 3.2 NDK are not as up-to-date as those in the 3.2.1 archive?

The NDK would also be a good place to put OS .cd and .ct files as well as example source code for .language and .country files.

Oh, @olsen… funny bug in workbench’ wbinfo window (not RAWBInfo), I find myself unable to type in } with the keyboard, { is fine, but } I have to paste in.

Some more «issues» I posted to the mostly quiet void that is the hyperion’s forum.

Last edited by kolla on 19-Mar-2022 at 03:55 PM.
Last edited by kolla on 19-Mar-2022 at 03:51 PM.

_________________
B5D6A1D019D5D45BCC56F4782AC220D8B3E2A6CC

@Chris_Y

Quote:

Chris_Y wrote: @olsen Is this the bit you want?

I think it might just be perfect, and the problem is not something which the preprocessor might have caused.

Quote:

Original code is: Quote: win_obj = (WindowObj, #ifdef __amigaos4__ WA_ToolBox, TRUE, #endif WA_Borderless, TRUE, WA_BusyPointer, TRUE, WINDOW_Position, WPOS_CENTERSCREEN, WINDOW_LockWidth, TRUE, WINDOW_LockHeight, TRUE, WINDOW_ParentGroup, (LayoutVObj, LAYOUT_AddImage, bm_obj = (BitMapObj,

And that seems to be the problem: LAYOUT_AddImage, bm_obj = (BitMapObj,

As we learned from vbcc testing, the combination of instantiating and assigning the resulting object to a variable can change how the TagItem list is built. It works for SAS/C but not necessarily in the same way for other compilers.

@olsen

Quote:

One could learn lessons from it, if the documentation were better, though

Olsen's Commentary on Amiga, 1st edition (with source code). I'd buy a copy.

_________________
"Unix is supposed to fix that." -- Jay Miner

@olsen

Quote:

And that seems to be the problem: LAYOUT_AddImage, bm_obj = (BitMapObj, As we learned from vbcc testing, the combination of instantiating and assigning the resulting object to a variable can change how the TagItem list is built. It works for SAS/C but not necessarily in the same way for other compilers.

How very strange. I've moved that to occur separately and just plug the final object in - however it still appears to return NULL

Not sure if I've missed some difference between 3.9/3.2/4.1 bitmap.image meaning my tags don't work?

_________________
"Miracles we do at once, the impossible takes a little longer" - AJS on Hyperion
Avatar is Tabitha by Eric W Schwartz

@Chris_Y

I believe there is difference between a image and image object,
look at some iconify examples in the OS4.1 SDK.

Last edited by NutsAboutAmiga on 19-Mar-2022 at 05:47 PM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS